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(b)  OMB  Circular  A-l  1,  Part  3,  July  1999  and  "Supplemental  Capital 
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Capital  Assets,"  July  1997 

(c)  USD(AT&L),  ASD(C3I),  and  DOT&E  Memorandum,  "Mandatory 
Procedures  for  Major  Defense  Acquisition  Programs  (MDAPs)  and 
Major  Automated  Information  System  (MAIS)  Acquisition  Programs,” 

January  4, 2001 

(d)  DoD  Directive  5025.1,  "DoD  Directives  System,"  July  27,  2000 

(e)  through  (ww),  see  enclosure  1 


1.  PURPOSE 
This  Instruction: 

1.1.  Establishes  a  simplified  and  flexible  management  framework  for  translating  mission 
needs  and  technological  opportunities,  based  on  validated  mission  needs  and  requirements,  into 
stable,  affordable,  and  well-managed  acquisition  programs  that  include  weapon  systems  and 
automated  information  systems. 

1 .2.  Establishes  a  general  approach  for  managing  acquisition  programs  while  acknowledging 
that  every  technology  project  and  acquisition  program  is  unique  and  that  any  particular  project  or 
program,  particularly  non-major  programs,  may  not  need  to  follow  the  entire  process. 

1.3.  Consistent  with  statutory  requirements  and  reference  (a),  authorizes  Milestone  Decision 
Authorities  (MDAs)  to  tailor  procedures  in  order  to  achieve  cost,  schedule,  and  performance 
goals. 

1.4.  Implements  reference  (a),  the  guidelines  of  OMB  Circular  A-l  1,  Part  3  (reference  (b)), 
and  current  laws,  and  the  procedures  in  reference  (c). 
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1.5.  Authorizes  the  publication  of  DoD  5000.2-R,  which  establishes  procedures  to  be 
followed  for  Major  Defense  Acquisition  Programs  (MDAPs),  Major  Automated  Information 
Systems  (MAISs),  and  those  non-major  systems  specifically  identified  in  the  Regulation  in 
accordance  with  DoD  Directive  5025.1  (reference  (d)). 


2.  APPLICABILITY  AND  SCOPE 
This  Instruction  applies  to: 

2.1.  The  Office  of  the  Secretary  of  Defense,  the  Military  Departments,  the  Chairman  of  the 
Joint  Chiefs  of  Staff,  the  Combatant  Commands,  the  Office  of  the  Inspector  General  of  the 
Department  of  Defense,  the  Defense  Agencies,  DoD  Field  Activities,  and  all  other  organizational 
entities  within  the  Department  of  Defense  (hereafter  referred  to  collectively  as  "the  DoD 
Components"). 

2.2.  All  defense  technology  projects  and  acquisition  programs.  Some  requirements,  where 
stated,  apply  only  to  MDAPs  and  MAISs. 

2.3.  In  general,  highly  sensitive  classified,  cryptologic,  and  intelligence  projects  and 
programs  shall  follow  the  guidance  in  this  Instruction  and  reference  (c)  for  technology  projects 
and  acquisition  programs  of  equivalent  acquisition  category.  The  MDA  shall  approve  proposed 
tailoring  of  the  systems  acquisition  process  for  these  projects  and  programs. 


3.  DEFINITIONS 

Terms  used  in  this  Instruction  are  defined  in  enclosure  2. 


4.  PROCEDURES 


4.1.  MDAs  shall  establish  mandatory  procedures  for  assigned  programs.  These  procedures 
shall  not  exceed  the  requirements  for  MDAPs  and  MAIS  acquisition  programs  established  in  this 
Instruction  or  in  reference  (c).  The  Heads  of  the  DoD  Components  shall  keep  the  issuance  of 
any  directives,  instructions,  policy  memorandums,  or  regulations  necessary  to  implement  the 
mandatory  procedures  contained  in  this  Instruction  and  reference  (c)  to  a  minimum.  The  Heads 
of  the  DoD  Components  shall  provide  copies  of  all  such  documents  to  the  Under  Secretary  of 
Defense  for  Acquisition,  Technology,  and  Logistics  (USD(AT&L))  PRIOR  TO  publication. 
Waivers  or  requests  for  exceptions  to  the  provisions  of  this  Instruction  shall  be  submitted  to  the 
USD(AT&L),  Assistant  Secretary  of  Defense  for  Command,  Control,  Communications,  and 
Intelligence  (ASD(C3I)),  or  Director  of  Operational  Test  and  Evaluation  (DOT&E),  as 
appropriate  via  the  Component  Acquisition  Executive  (CAE).  Statutory  requirements  cannot  be 
waived  unless  the  statute  specifically  provides  for  waiver  of  the  stated  requirements. 
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4.2.  The  DoD  Components  (including  Office  of  the  Secretary  of  Defense  (OSD)  staff 
offices)  shall  coordinate  proposed  policy  memorandums  and  changes  to  individual  sections  of 
this  Instruction  or  reference  (c)  with  the  Executive  Secretary  of  the  Defense  Acquisition  Policy 
Steering  Group  (DAPSG)  (reference  (e))  prior  to  Department-wide  staffing  of  the  change.  The 
purpose  of  this  policy  is  to  maintain  administrative  control  of  this  Instruction  and  is  not  intended 
to  imply  any  approval  authority  on  the  part  of  the  Executive  Secretary. 

4.3.  The  DAPSG  shall  submit  proposed  changes  to  the  USD(AT&L),  ASD(C3I),  and 
DOT&E,  who  jointly  have  the  authority  to  change  this  Instruction.  All  three  officials  shall 
jointly  sign  future  changes.  Proposed  changes  shall  be  considered  annually  by  the  Defense 
Acquisition  Policy  Working  Group  (DAPWG)  (see  reference  (e)). 

4.4.  This  Instruction  and  references  (a)  and  (c)  are  located  in  the  Reference  Library  of  the 
Defense  Acquisition  Deskbook  (reference  (f)).  Mandatory  and  discretionary  acquisition 
information,  practical  advice,  and  lessons  learned  are  also  located  in  the  Deskbook. 

4.5  Implementation  of  the  New  Acquisition  Process 

4.5. 1  New  Milestones.  Programs  planned  in  accordance  with  the  1996  version  of  DoD 
Directive  5000.1  (reference  (g))  and  the  1996  version  of  DoD  5000.2-R  (reference  (h))  shall  be 
executed  in  accordance  with  approved  program  documentation.  That  documentation  shall  not  be 
updated  solely  to  satisfy  the  requirements  of  this  Instruction.  Unless  otherwise  directed  by  the 
MDA,  the  new  decision  points  and  phases  in  this  Instruction  shall  be  applied  to  efforts  that  have 
not  yet  been  approved  as  acquisition  programs  (usually  pre-Milestone  I),  and  to  acquisition 
programs  that  are  pre-Milestone  II.  Unless  otherwise  directed  by  the  MDA,  the  new  decision 
points  and  phases  shall  not  be  applied  to  acquisition  programs  that  are  post-Milestone  II. 

4.5.2  Policies  and  Procedures.  The  new  policies  and  procedures  in  this  Instruction  shall 
be  applied  to  efforts  that  have  not  yet  been  approved  as  acquisition  programs,  and  to  all 
acquisition  programs,  including  those  planned  in  accordance  with  the  1996  version  of  DoD 
Directive  5000.1  (reference  (g))  and  DoD  5000.2-R  (reference  (h)). 

4.5.3  Compliance  with  Statutes.  For  purposes  of  complying  with  applicable  laws, 
Milestone  A  will  serve  as  Milestone  0;  Program  Initiation,  when  it  occurs  at  or  during 
Component  Advanced  Development,  will  serve  as  Milestone  I;  Milestone  B  will  serve  as 
Milestone  II;  Milestone  C  will  serve  as  the  Low-Rate  Initial  Production  decision  point;  and  the 
Full-Rate  Production  Decision  Review  will  serve  as  Milestone  III.  In  addition,  System 
Development  and  Demonstration  will  serve  as  Engineering  and  Manufacturing  Development. 

4.6.  Characteristics  of  the  Defense  Acquisition  System  Successful  Department  of  Defense 
acquisition  is  dependent  on  smooth  integration  of  the  three  principal  decision  systems  in  the 
Department  and  on  attention  to  critical  key  capability  enablers. 

4.6.1.  Integrated  Management  Framework.  The  policies  in  this  Instruction  are  intended 
to  forge  a  close  and  effective  interface  among  the  Department's  principal  decision  support 
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systems:  the  Requirements  Generation  System,  the  Defense  Acquisition  System,  and  the 
Planning,  Programming,  and  Budgeting  System. 

4.6.1. 1.  Requirements  Generation  System  The  Requirements  Generation  System 
(reference  (i))  produces  information  for  decision-makers  on  the  projected  mission  needs  of  the 
user.  The  user  defines  mission  needs  in  broad  operational  terms  and  then  evolves  the  needs  to 
specific  operational  requirements  (see  subparagraph  4.7.2. 1,  below).  The  Joint  Requirements 
Oversight  Council  (JROC),  or  other  appropriate  requirements  authority,  validates  and  approves 
the  mission  need,  confirms  the  fact  that  a  non-materiel  solution  alone  cannot  satisfy  the 
identified  need,  and  identifies  that  a  potential  new  concept  or  system  materiel  solution  should  be 
considered. 


4.6.1.2.  Defense  Acquisition  System 

4.6. 1.2.1.  The  Defense  Acquisition  System  establishes  a  management  process  to 
translate  user  needs  (broadly  stated  mission  needs  responding  to  a  postulated  threat  and 
developed  in  the  Requirements  Generation  System  or  business  needs  responding  to  new  ways  of 
doing  business  and  developed  by  the  appropriate  staff  office)  and  technological  opportunities 
(developed  or  identified  in  the  Science  and  Technology  program  based  on  user  needs)  into 
reliable  and  sustainable  systems  that  provide  capability  to  the  user. 

4.6. 1.2.2.  The  Defense  Acquisition  System  is  a  continuum  composed  of  three 
activities  with  multiple  paths  into  and  out  of  each  activity.  Technologies  are  researched, 
developed,  or  procured  in  pre-system  acquisition  (science  and  technology  and  concept 
development  and  demonstration).  Systems  are  developed,  demonstrated,  produced  or  procured, 
and  deployed  in  systems  acquisition.  The  outcome  of  systems  acquisition  is  a  system  that 
represents  a  judicious  balance  of  cost,  schedule,  and  performance  in  response  to  the  user's 
expressed  need;  that  is  interoperable  with  other  systems  (U.S.,  Coalition,  and  Allied  systems,  as 
specified  in  the  operational  requirements  document);  that  uses  proven  technology,  open  systems 
design,  available  manufacturing  capabilities  or  services,  and  smart  competition;  that  is 
affordable;  and  that  is  supportable.  Once  deployed,  the  system  is  supported  throughout  its 
operational  life  and  eventual  disposal  in  post-systems  acquisition  using  prudent  combinations  of 
organic  and  contractor  service  providers,  in  accordance  with  statutes. 

4.6.1.3.  Planning.  Programming,  and  Budgeting  System.  The  Planning, 
Programming,  and  Budgeting  System  (PPBS)  (reference  (j))  provides  for  a  cyclic  process  that 
provides  the  operational  commanders-in-chief  the  best  mix  of  forces,  equipment,  and  support 
attainable  within  fiscal  constraints. 

4.6. 1.4.  Integrated  Reviews.  As  new  ways  of  using  technology  development, 
evolutionary  acquisition,  and  interoperability  permeate  the  acquisition  process,  the  Department 
of  Defense  must  increasingly  review  programs  on  a  family-of-systems  basis,  as  well  as  conduct 
mission  area  reviews.  The  objective  of  these  more  comprehensive  reviews  is  to  better  reconcile 
requirements,  resources,  and  programs  to  support  the  goals  of  cost-effectiveness  and 
interoperability  and  to  assess  where  limited  resources  are  best  spent.  A  number  of  existing 
mechanisms  support  such  objectives,  including  front-end  assessments,  mission  area  assessments. 
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and  special  studies.  Any  of  these  mechanisms,  or  others,  may  be  used  to  conduct  family-of- 
systems  and  mission  area  reviews  on  a  selective  basis  to  support  requirements,  acquisition,  and 
budget  decisions. 

4.6.2.  Key  Capability  Enablers.  To  meet  operational  requirements  for  Joint,  Combined, 
and  Coalition  military  missions  across  warfighting  to  peace-keeping  spectrums,  all  systems  and 
families-of-systems  must  be  designed,  developed,  tested,  and  supported  to  ensure  protection  of 
Critical  Program  Information  information  superiority  and  interoperability. 

4.6.2. 1.  Critical  Program  Information 

4.6.2. 1.1.  Critical  Program  Information  (CPI)  is  program  information, 
technologies,  or  systems  that,  if  compromised,  would  degrade  combat  effectiveness,  shorten  the 
expected  combat  effective  life  of  the  system,  or  significantly  alter  program  direction.  This 
includes  classified  military  information  or  Controlled  Unclassified  Information  (CUI)  about  such 
program  information,  technologies,  or  systems. 

4.6.2. 1 .2.  The  identification  of  sensitive  information  and  technologies,  both 
classified  and  unclassified,  shall  be  accomplished  early  in  the  development  and  acquisition 
process.  The  process  shall  include  decisions  on  the  protection  of  this  information,  as  well  as  its 
transfer  to  foreign  governments  and  foreign  contractors  in  support  of  cooperative  programs, 
multinational  operations,  foreign  contracting,  and  foreign  sales.  This  information  shall  be 
reassessed  at  each  milestone  decision  point.  See  DoD  Directive  5200.39  (reference  (k))  and 
DoD  Directive  5230.11  (reference  (1))  for  additional  guidance. 

4.6.2.2.  Information  Superiority 

4. 6. 2. 2. 1.  Information  superiority  is  defined  as  the  capability  to  collect,  process, 
and  disseminate  an  uninterrupted  flow  of  information  while  exploiting  or  denying  an  adversary's 
ability  to  do  the  same.  Information  superiority  is  achieved  in  a  non-combat  situation  or  one  in 
which  there  are  no  clearly  defined  adversaries  when  friendly  forces  have  the  information 
necessary  to  achieve  operational  objectives. 

4.6.2.2.2.  Forces  will  attain  information  superiority  through  the  acquisition  of 
systems  and  families  of  systems  that  are  secure,  reliable,  interoperable,  and  able  to  communicate 
across  a  universal  information  technology  (IT)  infrastructure,  to  include  national  security 
systems  (NSS).  This  IT  infrastructure  includes  the  data,  information,  processes,  organizational 
interactions,  skills,  and  analytical  expertise,  as  well  as  systems,  networks,  and  information 
exchange  capabilities. 

4.6.2.2.3.  For  the  DoD  Components  to  provide  these  capabilities  in  a  cost- 
effective  manner,  they  must  identify  and  evaluate  IT  (including  NSS)  infrastructure  and 
supportability  and  interoperability  from  the  beginning  of  each  program's  life  cycle.  This 
identification  shall  include  appropriate  system  and  family  of  systems  requirements  associated 
with  critical  infrastructure  protection,  information  assurance,  space  control,  and  related  missions 
that  are  consistent  with  DoD  policies,  standards  (e.g.,  the  Joint  Technical  Architecture),  and 
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mission-area  integrated  architectures.  In  addition,  the  evaluation  of  IT  (including  NSS) 
supportability  and  interoperability  shall  be  documented  in  the  Command,  Control, 
Communications,  Computers,  and  Intelligence  Support  Plan  (C4ISP)  (reference  (c)).  The  results 
of  this  planning  shall  be  discussed  in  the  system  acquisition  strategy. 

4.6. 2.2.4.  All  programs  shall  be  managed  and  engineered  using  best  processes 
and  practices  to  reduce  security  risks;  ensure  programs  are  synchronized;  be  designed  to  be 
mutually  compatible  with  other  electric  or  electronic  equipment  and  the  operational 
electromagnetic  environment;  identify  Critical  Program  Information  that  requires  protection  to 
prevent  unauthorized  disclosure  or  inadvertent  transfer  of  leading-edge  technologies  and 
sensitive  data  or  systems;  require  hardening,  redundancy,  or  other  physical  protection  against 
attack;  be  certified  for  spectrum  supportability;  and  comply  with  the  provisions  of  the  Clinger- 
Cohen  Act  (CCA)  (reference  (m)).  Requirements  for  data  structure  and  quality  of  information 
that  support  DoD  Information  Superiority  objectives  are  defined  in  DoD  Directive  8000.1 
(reference  (n))  and  DoD  Directive  8320.1  (reference  (o)).  Policy  and  process  for  ensuring 
information  interoperability  of  IT  (including  NSS)  is  prescribed  in  DoD  Directive  4630.5 
(reference  (p))  and  DoD  Instruction  4630.8  (reference  (q)). 

4.6.2.3.  Interoperability 

4.6.2. 3. 1.  Interoperability  is  the  ability  of  systems,  units,  or  forces  to  provide 
data,  information,  materiel,  and  services  to  and  accept  the  same  from  other  systems,  units,  or 
forces,  and  to  use  the  data,  information,  materiel,  and  services  so  exchanged  to  enable  them  to 
operate  effectively  together.  The  use  of  mission  area  (i.e.,  joint  mission  area  and/or 
business/administrative  mission  areas)  integrated  architectures  shall  characterize  IT,  including 
Natinal  Security  System  (NSS),  interoperability  requirements.  The  Joint  Operational 
Architecture  and  the  Joint  Technical  Architecture  shall  serve  as  the  foundation  for  development 
of  the  mission  area  integrated  architectures.  Mission  area  integrated  architectures  shall  relate  IT, 
including  NSS,  interoperability  requirements  in  a  family-of-systems  mission  area  context.  The 
user  shall  derive  IT,  including  NSS,  family-of-systems  information  exchange  requirements 
(IERs)  from  the  operational  IER  of  the  mission  area  integrated  architecture.  During  the 
requirements  generation  process,  users  shall  develop  interoperability  key  performance  parameter 
(KPP)  in  accordance  with  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Instruction  3 170.01A 
(reference  (i))  and  CJCS  Instruction  6212.01B  (reference  (r))  for  all  Capstone  Requirements 
Documents  (CRDs)  and  Operational  Requirements  Documents  (ORDs).  Interoperability  needs 
shall  be  addressed  as  part  of  the  Mission  Need  Statement  (MNS)  constraint  section. 
Interoperability  constraints  will  form  the  basis  for  the  CRD  and  ORD  interoperability  KPPs.  For 
the  acquisition  community,  the  interoperability  requirements  established  in  the  requirements 
process  shall  be  allocated  from  the  requirements  documents  to  the  individual  systems  through  the 
system  engineering  process. 

4.6.2.3.2.  Interoperability  requirements  shall  be  addressed  in  the  C4ISP 
(reference  (c))  and  in  integration  plans  for  non-information  interoperability  requirements.  The 
results  of  this  planning  shall  be  discussed  in  the  system  acquisition  strategy. 
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4.6.23.3.  The  MDA  shall  make  decisions  on  individual  programs  in  the  context 
of  the  family  of  systems.  Those  decisions  shall  be  supported  by  the  information  provided  by  the 
Program  Manager  (PM)  in  the  acquisition  strategy. 

4.6.23.4.  The  DOT&E  shall  consider  interoperability  as  part  of  all  early 
operational  assessments,  initial  operational  test  and  evaluations,  and  test  plans  to  ensure 
interoperability  is  adequately  tested  and  evaluated. 

4.6.23.5.  In  view  of  their  importance  in  achieving  interoperability,  DoD 
Components  shall  fully  fund  their  share  of  approved  joint  and  international  cooperative  program 
commitments.  In  situations  where  joint  and  international  cooperative  programs  will  not  be  fully 
funded,  DoD  Components  shall  follow  the  procedures  in  reference  (c). 

4.7.  The  Defense  Acquisition  Management  Framework 

4.7.1.  General 

4.7. 1.1.  All  projects  and  programs,  including  highly  sensitive  classified, 
cryptologic,  and  intelligence  projects  and  programs,  shall  accomplish  activities  described  in  this 
Instruction  and  reference  (c)  (for  MDAPs,  MAISs,  and  non-major  systems  as  specified  in  the 
Regulation).  How  these  activities  are  conducted  shall  be  determined  on  a  project-by-project  or 
program-by-program  basis  through  Integrated  Product  Teams  (IPTs)  and  Integrated  Product  and 
Process  Development  (IPPD).  How  these  activities  are  conducted  shall  be  tailored  to  minimize 
the  time  it  takes  to  satisfy  an  identified  need  consistent  with  common  sense  and  sound  business 
practice. 


4.7. 1.2.  Extensive  use  of  modeling,  simulation,  and  analysis  should  be  used 
throughout  the  acquisition  process  to  integrate  the  activities  of  the  principal  decision  support 
systems  by  creating  information  for  decision-makers.  Modeling  and  simulation  (M&S)  is  useful 
in  representing  conceptual  systems  that  do  not  exist  and  extant  systems  that  cannot  be  subjected 
to  actual  environments  because  of  safety  requirements  or  the  limitations  of  resources  and 
facilities.  The  Program  Manager  should  plan  for  the  integrated  use  of  M&S  that  maximizes  the 
use  of  existing  M&S  before  developing  program  unique  products. 

4.7.13.  Development  and  procurement  of  a  system  is  not  the  only  type  of  solution 
that  can  satisfy  a  mission  need.  Procurement  of  services  shall  be  considered  as  a  way  of  meeting 
the  operational  requirements  at  a  reasonable  cost  to  the  Department  of  Defense. 

4.7. 1.4.  At  each  milestone  review,  the  MDA  shall  assess  the  opportunities  for 
cooperative  development  or  procurement.  The  MDA  shall  make  this  assessment  based  on  an 
assessment  of  whether  or  not  a  project  or  program  similar  to  the  one  under  consideration  is  in 
development  or  production  by  one  or  more  major  allies  or  NATO  organizations;  if  such  a  project 
or  program  exists,  determining  if  that  project  could  satisfy,  or  be  modified  in  scope  to  satisfy, 
U.S.  military  requirements;  and  assess  the  advantages  and  disadvantages  with  regard  to  program 
timing,  developmental  and  life-cycle  costs,  technology  sharing,  and  interoperability  with  one  or 
more  major  allies  or  NATO  organizations. 
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4.7.1.5.  Throughout  the  life  of  a  technology  project,  service  contract,  or  acquisition 
program,  cost-effective  competition  (at  both  the  prime  and  sub-contractor  levels)  shall  be 
maintained  to  the  maximum  extent  practical  by  means  of  either  head-to-head  competition, 
competition  of  alternative  ways  to  meet  the  mission  need,  reliance  on  market  surveys  for 
commercial  alternatives,  or  changing  requirements  (through  the  process  of  cost  and  performance 
trades)  to  allow  increased  competition.  This  competition  for  best  value  to  the  Department  of 
Defense  shall  be  identified  in  the  acquisition  strategy.  Wherever  possible  and  appropriate, 
performance-  and  price-based  acquisition  methods  should  be  used.  The  benefits  of  long-term 
contracting  shall  be  explored.  Contractors  shall  be  encouraged  to  submit  realistic  cost  proposals, 
including  fair  and  reasonable  profit  or  fee  amounts.  "Buy-ins"  shall  be  discouraged  because  they 
may  decrease  competition  or  lead  to  poor  contract  performance.  Cost  proposals  shall  be 
evaluated  to  ensure  cost-realism  in  accordance  with  the  Federal  Acquisition  Regulation 
(reference  (s)).  Costs  shall  be  tested  to  ensure  cost-realism  (based  on  knowledge  gained  during 
the  acquisition  process).  Acquisitions  shall  be  structured  in  such  a  way  that  undue  risk  (such  as 
through  the  use  of  firm  fixed  price  options  that  cover  more  than  five  years)  is  not  imposed  on 
contractors,  and  so  that  excessive  contractor  investment  (beyond  normal  investments  for  plant, 
equipment,  etc.)  is  not  required.  Contractors  are  entitled  to  earn  reasonable  rewards  on  DoD 
contracts,  including  competitively  awarded  contracts.  If  competition  is  not  available,  PMs  shall 
devise  incentives  to  motivate  contractors  in  a  way  that  will  yield  the  benefits  of  competition. 
These  benefits  include  innovation,  improved  product  quality  and  performance,  increased 
efficiency,  and  lower  costs. 

4.7. 1.6.  Programs  entering  system  acquisition  will  comply  with  requirements 
governing  new  starts  (reference  (j)). 

4.7. 1.7.  At  each  Milestone  and  at  the  Full-Rate  Production  Decision,  the  MDA  has 
the  option  to  continue  the  project  or  program,  modify  the  project  or  program,  terminate  the 
project  or  program,  or  proceed  into  the  next  phase.  The  MDA  may  hold  other  reviews  to  adjust 
plans,  review  progress,  or  determine  how  to  proceed  to  production. 

4.7. 1.8.  While  a  materiel  alternative  may  enter  acquisition  at  multiple  points,  the 
appropriate  point  is  guided  by  the  ability  to  satisfy  stated  entrance  criteria,  the  content  of  each 
work  effort  within  a  phase,  and  the  considerations  at  each  milestone.  Entrance  criteria  are 
minimum  accomplishments  required  to  be  completed  by  each  program  prior  to  entry  into  the 
next  phase  or  work  effort. 

4.7. 1.9.  There  is  no  one  best  way  to  accomplish  the  objectives  of  the  Defense 
Acquisition  System.  Proposed  programs,  for  example,  may  enter  the  acquisition  process  at 
various  decision  points,  depending  on  concept  and  technological  maturity.  Decision-makers  and 
Program  Managers  shall  tailor  acquisition  strategies  to  fit  the  particular  conditions  of  an 
individual  program,  consistent  with  common  sense,  sound  business  management  practice, 
applicable  laws  and  regulations,  and  the  time-sensitive  nature  of  the  user's  requirement. 

Tailoring  shall  be  applied  to  various  aspects  of  the  Acquisition  system,  including  program 
documentation,  acquisition  phases,  the  timing  and  scope  of  decision  reviews,  and  decision  levels. 
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Milestone  decision  authorities  shall  promote  flexible,  tailored  approaches  to  oversight  and 
review  based  on  mutual  trust  and  a  program's  dollar  value,  risk,  and  complexity. 

4.7.1.10.  A  graphic  representation  of  the  Defense  acquisition  management 
framework  is  shown  in  Figure  FI.  The  framework  is  divided  into  three  activities  (e.g.,  Systems 
Acquisition).  Activities  are  divided  into  phases  (e.g.,  System  Development  and  Demonstration). 
Phases  are  divided  into  work  efforts  (e.g.,  System  Integration).  The  remainder  of  this  section 
will  discuss  each  aspect  of  the  framework. 


Figure  FI. 
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4.7.2.  Pre-Systems  Acquisition  Pre-system  acquisition  is  composed  of  on-going 
activities  in  development  of  user  needs,  in  science  and  technology,  and  in  concept  development 
work  specific  to  the  development  of  a  materiel  solution  to  an  identified,  validated  need.  The 
responsible  authority  outside  of  this  Instruction  defines  policies  and  directives  for  development 
of  user  needs  and  technological  opportunities  in  science  and  technology. 
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Figure  F2. 
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4.7.2. 1.  User  Need  Activities.  The  MNS  shall  identify  and  describe  the  projected 
mission  needs  of  the  user  in  the  context  of  the  threat  to  be  countered  or  business  need  to  be  met. 
The  user  representative,  with  support  from  the  operational  test  and  evaluation  community, 
develops  the  needs  expressed  in  the  MNS  into  requirements  in  the  form  of  CRDs  (if  applicable) 
and  ORDs.  CRDs  contain  capabilities-based  requirements  that  facilitate  the  development  of 
individual  ORDs  by  providing  a  common  framework  and  operational  concept  to  guide  their 
development.  The  CRD  is  an  oversight  tool  for  overarching  requirements  for  a  family  of 
systems  (reference  (i)).  Validated  ORDs  translate  the  MNS  and,  if  applicable,  CRDs  into  broad, 
flexible,  and  time-phased  operational  goals  that  are  further  detailed  and  refined  into  specific 
operational  capability  requirements  contained  in  the  final  ORD  at  System  Demonstration.  The 
appropriate  requirements  authority  shall  validate  all  MNSs,  CRDs,  and  ORDs. 

4.7.2. 1.1.  In  the  process  of  refining  requirements,  the  user  shall  adhere  to  the 
following  key  concepts  (in  accordance  with  reference  (i)): 

4.7.2. 1.1.1.  Keep  all  reasonable  options  open  and  facilitate  cost,  schedule, 
and  performance  trades  throughout  the  acquisition  process. 

4.7.2. 1.1. 2.  Avoid  early  commitments  to  system-specific  solutions,  including 
those  that  inhibit  future  insertion  of  new  technology  and  commercial  or  non-developmental 
items. 


4.7.2. 1.1. 3.  Define  requirements  in  broad  operational  capability  terms. 

4.7.2. 1.1. 4.  Develop  time-phased  requirements  with  associated  objectives  and 
thresholds  (as  appropriate). 

4.7.2. 1.1. 5.  Evaluate  how  the  desired  performance  requirements  could 
reasonably  be  modified  to  facilitate  the  potential  use  of  commercial  or  non-developmental  items 
and  components. 
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4.7.2. 1.1. 6.  Evaluate  whether  system  will  be  able  to  survive  and  operate 
through  the  anticipated  threat  environment. 

4.7.2. 1.1. 7.  Consider  Critical  Program  Information  needs,  anti-tamper,  and 
intelligence  support  requirements. 

4.7.2. 1.1. 8.  Address  cost  in  the  ORD,  in  terms  of  a  threshold  and  objective. 

4.7.2. 1.1. 9.  Include  requirements  for  security,  information  assuredness,  and 
critical  infrastructure  protection  with  consideration  of  releasability  criteria  for  multinational 
operational  environments. 

4.7.2.1.1.10.  Consider  supportability,  data  sharing,  and  interoperability  needs 
of  the  family  of  systems  in  the  operational  environment. 

4.7.2. 1 . 1 . 1 1 .  Mandate  interoperability  as  a  key  performance  parameter  (KPP) 
to  be  documented  in  all  ORDs  and  CRDs  (reference  (i))  and  included  in  the  Acquisition  Program 
Baseline  (APB)  (reference  (c)). 

4.7.2. 1.2.  For  purposes  of  interoperability  and  supportability,  all  IT  (including 
NSS)  acquisition  programs  regardless  of  acquisition  category,  developed  for  use  by  U.S.  forces 
are  for  joint,  combined,  and  coalition  use.  The  intent  is  to  develop,  acquire,  and  deploy  IT  that 
meet  essential  operational  needs  of  U.S.  forces.  Interoperability  and  integration  of  IT 
requirements  shall  be  determined  during  the  requirements  validation  process  by  the  DoD 
Components  and  Joint  Staff  (through  review  of  all  MNSs  and  ORDs)  and  shall  be  updated  as 
necessary  throughout  the  acquisition,  deployment,  and  operational  life  of  a  system.  Given  the 
potential  joint  nature  of  AISs,  all  AIS  MNSs  and  ORDs  shall  be  submitted  to  the  Joint  Staff  in 
accordance  with  CJSC  Instruction  3 170.01  A  (reference  (i))  to  determine  if  there  is  JROC  special 
interest. 


4.7.2. 1.3.  The  Chairman  of  the  Joint  Chiefs  of  Staff  shall  establish  procedures  for 
the  development,  coordination,  review,  and  validation  of  interoperability  and  supportability 
requirements  for  IT  (including  NSS)  acquisition  programs ,  regardless  of  acquisition  category. 
The  Chairman  shall  approve,  document,  and  exercise  doctrinal  concepts  and  associated 
operational  procedures  to  achieve  interoperability  and  supportability  of  IT  (including  NSS) 
acquisition  programs  employed  by  U.S.  forces  and  with  coalition  and  allied  forces.  The 
Chairman  has  established  procedures  for  ensuring  compliance  with  certification  of  joint 
interoperability  of  IT  (including  NSS)  acquisition  programs  throughout  their  life  cycle  and 
ensure  that  the  Directors  of  the  Defense  Agencies  are  included  in  the  review  process  (reference 
(r))- 


4.7.2. 1 .4.  The  user  or  user's  representative  shall  work  with  the  Program  Manager 
or  other  system  developer  (e.g.,  the  Demonstration  Manager  for  Advanced  Concept  and 
Technology  Development  projects)  to  establish  and  refine  cost  as  an  independent  variable 
(CAIV)-based  cost  and  performance  objectives  and  critical  schedule  dates.  The  CAIV-based 
parameters  and  critical  schedule  dates  shall  also  be  included  in  the  APB. 
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4.7.2.2.  Materiel  Acquisition  Requirement  Questions.  Before  proposing  a  new 
acquisition  program,  DoD  Components  shall  affirmatively  answer  the  following  questions: 

4.7.2.2.1.  Does  the  acquisition  support  core/priority  mission  functions  that  need 
to  be  performed  by  the  Federal  Government? 

4.1.22.2.  Does  the  acquisition  need  to  be  undertaken  by  the  DoD  Component 
because  no  alternative  private  sector  or  governmental  source  can  better  support  the  function? 

4.7.2.2.3.  Does  the  acquisition  support  work  processes  that  have  been  simplified 
or  otherwise  redesigned  to  reduce  costs,  improve  effectiveness,  and  make  maximum  use  of 
commercial  off-the-shelf  technology? 

4.7.2.3.  Technological  Opportunity  Activities.  Technological  opportunities  within 
DoD  laboratories  and  research  centers,  from  academia,  or  from  commercial  sources  are 
identified  within  the  Defense  Science  and  Technology  (S&T)  Program.  The  DoD  S&T  Program 
mission  is  to  provide  the  users  of  today  and  tomorrow  with  superior  and  affordable  technology  to 
support  their  missions,  and  to  enable  them  to  have  revolutionary  war-winning  capabilities.  The 
S&T  Program  is  uniquely  positioned  to  reduce  the  risks  of  promising  technologies  before  they 
are  assumed  in  the  acquisition  process.  The  Deputy  Under  Secretary  of  Defense  (Science  & 
Technology)  (DUSD(S&T))  is  responsible  for  the  overall  direction,  quality,  content,  and 
oversight  of  the  DoD  S&T  Program  (including  software  capability).  The  DUSD(S&T)  is  also 
responsible  for  promoting  coordination,  cooperation,  and  mutual  understanding  of  the  S&T 
program  within  the  Department  of  Defense,  other  Federal  Agencies,  and  the  civilian  community. 

4.7.2.3.1.  S&T  Program  Content.  The  S&T  program  consists  of  the  following: 

4.7.2.3.1.1.  Basic  Research  Scientific  study  and  experimentation  directed 
toward  increasing  knowledge  and  understanding  in  the  science  fields  and  discovering 
phenomena  that  can  be  exploited  for  military  purposes. 

4.7.2.3.1.2.  Applied  Research  Translates  promising  research  into  solutions 
for  broadly  defined  military  problems  with  effort  that  may  vary  from  applied  research  to 
sophisticated  breadboard  subsystems  that  establish  the  initial  feasibility  and  practicality  of 
proposed  solutions  or  technologies. 

4.7.2.3.1.3.  Advanced  Technology.  Demonstrates  the  performance  payoff, 
increased  logistics  or  interoperability  capabilities,  or  cost  reduction  potential  of  militarily 
relevant  technology. 

4.7.2. 3.2.  Technology  Transition  Objectives.  The  DUSD(S&T)  shall  provide 
support  and  oversight  to  the  Component  S&T  Executives  as  they  execute  their  statutory 
responsibilities.  They  shall: 
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4.123.2. 1 .  Evaluate  battlefield  deficiencies  as  defined  by  the  Joint  Chiefs  of 
Staff,  Commanders-in-Chief  (CINCs),  and  the  Military  Departments  against  ongoing  S&T 
efforts. 


4.1.23.2.2.  Establish  S&T  projects  when  on-going  S&T  efforts  are  not 
available  to  address  deficiencies. 

4.1.23.23.  Support  the  increased  use  of  commercial  technologies  through  the 
initiation  of  dual-use  technology  development  projects  to  address  deficiencies  for  both  hardware 
and  software. 


4.1.23.2.4.  For  those  technologies  with  the  most  promise  for  application  to 
weapon  systems  or  AISs,  be  responsible  for  maturing  technology  to  a  readiness  level  that  puts 
the  receiving  MDA  at  low  risk  for  systems  integration  and  acceptable  to  the  cognizant  MDA,  or 
until  the  MDA  is  no  longer  considering  that  technology. 

4.7.2.3.2.5.  Advise  the  requirements  and  acquisition  communities  of  new 
technology  developments  and  options  that  will  contribute  to  meeting  future  warfighting 
objectives  and  ensure  that  technical  advice  is  available  to  PMs  throughout  the  system 
development  process. 

4.7.23.2.6.  Conduct  independent  technology  assessments  and  assist  in 
determining  the  maturity  of  critical  system  technologies  for  transition  to  the  System  Acquisition 
process,  during  System  Development  and  Demonstration  and  at  Milestone  C. 

4.7.23.2.7.  Identify  Critical  Program  Information  (CPI),  both  classified  and 
unclassified,  requiring  security  protection. 

4.7.23.2.8.  Obtain  approval  of  appropriate  disclosure  authority  for  S&T 
projects  prior  to  formalizing  the  sharing  of  critical  research  and  technology  information  with 
foreign  governments  and  international  organizations. 

4.7.233.  Technology  Transition  Mechanisms.  To  ensure  the  transition  of 
innovative  concepts  and  superior  technology  to  the  user  and  acquisition  customer,  the  DoD 
Component  S&T  Executives  shall  use  three  mechanisms:  Advanced  Technology 
Demonstrations  (ATDs),  Advanced  Concept  Technology  Demonstrations  (ACTDs),  and 
Experiments,  both  joint  and  Service-specific.  The  specific  plans  and  processes  for  these 
transition  mechanisms  are  described  in  the  Joint  Warfighting  S&T  Plan  and  the  individual  DoD 
Component  S&T  Plans.  S&T  activities  shall  be  conducted  in  a  way  that  facilitates  or  at  least 
does  not  preclude  the  availability  of  competition  for  future  acquisition  programs. 

4.7.2.33.1.  ATDs  shall  be  used  to  demonstrate  the  maturity  and  potential  of 
advanced  technologies  for  enhanced  military  operational  capability  or  cost  effectiveness. 

4.7.233.2.  ACTDs  shall  be  used  to  determine  military  utility  of  proven 
technology  and  to  develop  the  concept  of  operations  that  will  optimize  effectiveness. 
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4.7.2.3.3.3.  Experiments  shall  be  used  to  develop  and  assess  concept-based 
hypotheses  to  identify  and  recommend  the  best  value-added  solutions  for  changes  to  doctrine, 
organizational  structure,  training  and  education,  materiel,  leadership,  and  people  required  to 
achieve  significant  advances  in  future  joint  operational  capabilities. 

4.7.2.4.  Analyze  Alternatives  and  Develop  Concepts  and  Technologies.  One  path 
into  systems  acquisition  begins  with  examining  alternative  concepts,  including  cooperative 
opportunities  and  procurement  or  modification  of  Allied  systems  or  equipment,  to  meet  a  stated 
mission  need.  This  path  begins  with  a  decision  to  enter  Concept  and  Technology  Development 
at  Milestone  A.  The  phase  ends  with  a  selection  of  a  system  architecture(s)  and  the  completion 
of  entrance  criteria  for  Milestone  B  and  System  Development  and  Demonstration  Phase. 

Figure  F3. 
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4.7.2.4.1.  Entrance  Criteria.  After  the  requirements  authority  validates  and 
approves  a  MNS,  the  MDA  (through  the  IPT  process)  will  review  the  MNS,  consider  possible 
technology  issues  (e.g.,  technologies  demonstrated  in  ATDs),  and  identify  possible  alternatives 
before  making  a  Milestone  A  decision.  The  decision  shall  not  be  made  final  until  a  thorough 
analysis  of  multiple  concepts  to  be  studied,  including  international  systems  from  Allies  and 
cooperative  opportunities  (see  10  U.S.C.  §2350a,  reference  (t)),  has  been  completed.  If  an 
international  system  is  selected,  the  program  shall  enter  systems  acquisition  activities  at 
Milestone  B  or  C. 

4.7.2.4.2.  Milestone  A 

4.7.2.4.2.I.  At  Milestone  A,  the  MDA  shall  approve  the  initiation  of  concept 
studies,  designate  a  lead  Component,  approve  Concept  Exploration  exit  criteria,  and  issue  the 
Acquisition  Decision  Memorandum.  The  leader  of  the  concept  development  team,  working  with 
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the  integrated  test  team,  shall  develop  an  evaluation  strategy  that  describes  how  the  capabilities 
in  the  MNS  will  be  evaluated  once  the  system  is  developed.  That  evaluation  strategy  shall  be 
approved  by  the  DOT&E  and  the  cognizant  OIPT  leader  180  days  after  Milestone  A  approval. 

4.7.2A2.2.  A  favorable  Milestone  A  decision  DOES  NOT  yet  mean  that  a 
new  acquisition  program  has  been  initiated. 

4.7.2.4.2.3.  The  tables  in  enclosure  3  identify  all  statutory  and  regulatory 
requirements  applicable  to  Milestone  A. 

4.7.2.4.2.4.  Milestone  A  approval  can  lead  to  Concept  Exploration  or 
Component  Advanced  Development  depending  on  whether  an  evaluation  of  multiple  concepts  is 
desired  or  if  a  concept  has  been  chosen,  but  more  work  is  needed  on  key  sub-systems  or 
components  before  a  system  architecture  can  be  determined  and  the  technologies  can  be 
demonstrated  in  a  relevant  environment. 

4.7.2.4.3.  Concept  Exploration 

4.7.2.4.3.1.  Concept  Exploration  typically  consists  of  competitive,  parallel, 
short-term  concept  studies.  The  focus  of  these  efforts  is  to  define  and  evaluate  the  feasibility  of 
alternative  concepts  and  to  provide  a  basis  for  assessing  the  relative  merits  (i.e.,  advantages  and 
disadvantages,  degree  of  risk,  etc.)  of  these  concepts.  Analyses  of  alternatives  shall  be  used  to 
facilitate  comparisons  of  alternative  concepts. 

4.7.2.4.3.2.  In  order  to  achieve  the  best  possible  system  solution,  emphasis 
will  be  placed  on  innovation  and  competition.  To  this  end,  participation  by  a  diversified  range  of 
businesses  (i.e.,  small,  new,  domestic,  and  international)  should  be  encouraged.  Alternative 
system  design  concepts  will  be  primarily  solicited  from  private  industry  and,  where  appropriate, 
from  organic  activities,  international  technology  and  equipment  firms,  Federal  laboratories, 
federally  funded  research  and  development  centers,  educational  institutions,  and  other  not-for- 
profit  organizations. 

4.7.2.4.33.  The  work  in  Concept  Exploration  normally  shall  be  funded  only 
for  completion  of  concept  studies  contracts.  The  work  shall  be  guided  by  the  MNS. 

4.7.2.43.4.  The  most  promising  system  concepts  shall  be  defined  in  terms  of 
initial,  broad  objectives  for  cost,  schedule,  and  performance;  identification  of  interoperability, 
security,  survivability,  operational  continuity,  technology  protection,  operational  support,  and 
infrastructure  requirements  within  a  family  of  systems;  opportunities  for  tradeoffs,  and  an  overall 
acquisition  strategy  and  test  and  evaluation  strategy  (including  Development  Test  and  Evaluation 
(DT&E),  Operational  Test  and  Evaluation  (OT&E),  and  Live  Fire  Test  and  Evaluation 
(LFT&E)).  The  DoD  Components  shall  also  consider  initiating  governnient-to-government 
efforts  to  develop  international  cooperation  in  attaining  the  most  promising  system  concepts. 

4.7.2.43.5.  This  work  effort  ends  with  a  review,  at  which  the  MDA  selects 
the  preferred  concept  to  be  pursued  for  which  technologies  are  available. 
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4.7.2.4A  Decision  Review.  During  Concept  Exploration,  the  MDA  may  hold  a 
decision  review  to  determine  if  additional  component  development  is  necessary  before  key 
technologies  will  be  sufficiently  mature  to  enter  System  Development  and  Demonstration  for  one 
of  the  concepts  under  consideration.  If  the  concepts  do  not  require  technologies  necessitating 
additional  component  development,  the  appropriate  milestone  (B  or  C)  shall  be  held  in  place  of 
this  review. 


4.7.2.4.5.  Program  Initiation  In  Advance  of  Milestone  B.  The  practical  result  of  a 
preference  for  more  mature  technology  is  initiation  of  individual  programs  at  later  stages  of 
development,  after  determination  of  technology  maturity.  As  a  consequence,  most  MDAPs  will 
be  initiated  at  Milestone  B.  On  the  rare  occasions  when  an  earlier  program  initiation  is 
appropriate,  it  will  take  place  at  entry  to  or  during  Component  Advanced  Development.  At 
program  initiation  in  advance  of  Milestone  B,  the  MDA  shall  approve  the  acquisition  strategy, 
the  acquisition  program  baseline,  IT  certification  for  MAISs  (reference  (u)),  and  exit  criteria  for 
the  Component  Advanced  Development  work  effort  if  not  already  established. 

4.7.2.4.6.  Component  Advanced  Development.  The  project  shall  enter 
Component  Advanced  Development  when  the  project  leader  has  a  concept  for  the  needed 
capability,  but  does  not  yet  know  the  system  architecture.  Unless  otherwise  determined  by  the 
MDA,  the  component  technology  to  be  developed  shall  have  been  proven  in  concept.  The 
project  shall  exit  Component  Advanced  Development  when  a  system  architecture  has  been 
developed  and  the  component  technology  has  been  demonstrated  in  the  relevant  environment  or 
the  MDA  decides  to  end  this  effort.  This  effort  is  intended  to  reduce  risk  on  components  and 
subsystems  that  have  only  been  demonstrated  in  a  laboratory  environment  and  to  determine  the 
appropriate  set  of  subsystems  to  be  integrated  into  a  full  system.  This  work  effort  normally  will 
be  funded  only  for  the  advanced  development  work.  The  work  effort  will  be  guided  by  the 
validated  MNS,  but  during  this  activity,  an  ORD  shall  be  developed  to  support  program 
initiation.  Also,  acquisition  information  necessary  for  a  milestone  decision  (e.g.,  the  acquisition 
strategy,  program  protection  plan,  etc.)  shall  be  developed.  This  effort  is  normally  followed  by 
entry  into  the  System  Development  and  Demonstration  phase  after  a  Milestone  B  decision  by  the 
MDA. 


4.7.3.  Systems  Acquisition 
4.7.3. 1.  General 

4.7.3. 1.1.  Systems  acquisition  is  the  process  of  developing  concepts  into 
producible  and  deployable  products  that  provide  capability  to  the  user.  The  concept  to  exploit  in 
systems  acquisition  is  based  on  an  analysis  of  alternative  ways  to  meet  the  military  need  (done 
either  in  Concept  Exploration  or  technological  opportunities  development),  including 
commercial  and  non-developmental  technologies  and  products  and  services  determined  through 
market  analysis.  The  DoD  Component  (or  appropriate  principal  staff  office  for  MAIS  programs) 
responsible  for  the  mission  area  in  which  a  deficiency  or  opportunity  has  been  identified,  but  not 
the  PM,  shall  normally  prepare  the  analysis  of  alternatives  (although  the  PM  or  PM's 
representative  may  participate  in  the  analysis). 
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4.7.3. 1.2.  The  goal  is  to  develop  the  best  overall  value  solution  over  the  system's 
life  cycle  that  meets  the  user's  operational  requirements.  Generally,  use  or  modification  of 
systems  or  equipment  that  the  DoD  Components  already  own  is  more  cost  and  schedule-effective 
than  acquiring  new  materiel.  If  existing  U.S.  military  systems  or  other  on-hand  materiel  cannot 
be  economically  used  or  modified  to  meet  the  operational  requirement,  an  acquisition  program 
may  be  justified  and  acquisition  decision-makers  shall  follow  the  following  hierarchy  of 
alternatives:  the  procurement  (including  modification)  of  commercially  available  domestic  or 
international  technologies,  systems  or  equipment,  or  the  additional  production  (including 
modification)  of  previously-developed  U.S.  military  systems  or  equipment,  or  Allied  systems  or 
equipment;  cooperative  development  program  with  one  or  more  Allied  nations;  new  joint 
Component  or  Government  Agency  development  program;  and  a  new  Component-unique 
development  program.  Important  in  this  evaluation  process  for  new  or  modified  systems  are 
considerations  for  interoperability  and  supportability  with  existing  and  planned  future 
components  or  systems. 

4.7.3. 1.3.  The  use  of  Allied  systems  and  equipment  is  a  preferred  source  of 
meeting  user  requirements.  DoD  places  great  weight  on  interoperability  of  equipment  with 
Allied  governments  and  coalition  partners  and  on  Allied  participation  in  DoD  acquisition 
programs  through  cooperative  development  and  production  and  through  sales  of  U.S.  equipment. 
Accordingly,  potential  foreign  participation  shall  be  considered  as  part  of  the  acquisition  strategy 
approved  for  Milestone  B,  to  be  reviewed  at  each  subsequent  major  decision  point.  In  addition, 
the  PM  shall  specifically  consider  and  be  responsible  for  proposing  program  disclosure  guidance 
at  each  major  decision  point.  The  PM  shall  ensure  that  appropriate  measures  are  in  place  to 
protect  Critical  Program  Information  and  that  appropriate  anti-tampering  measures  are  taken,  at 
all  times. 


4.7.3. 1 .4.  DoD  acquisition  and  procurement  of  weapons  and  weapon  systems 
shall  be  consistent  with  all  applicable  domestic  law  and  all  applicable  treaties,  customary 
international  law,  and  the  law  of  armed  conflict  (also  known  as  the  laws  and  customs  of  war). 

The  Head  of  each  DoD  Component  shall  ensure  that  all  Component  activities  that  could 
reasonably  generate  questions  concerning  compliance  with  obligations  under  arms  control 
agreements  to  which  the  United  States  is  a  party  shall  have  clearance  from  the  USD(AT&L),  in 
coordination  with  the  General  Counsel,  DoD,  and  the  Under  Secretary  of  Defense  (Policy), 
before  such  activity  is  undertaken.  The  Head  of  each  DoD  Component  shall  ensure  that  the 
Component's  General  Counsel  or  Judge  Advocate  General,  as  appropriate,  conducts  a  legal 
review  of  the  intended  acquisition  of  a  potential  weapon  or  weapon  system  to  determine  that  it  is 
consistent  with  U.S.  obligations.  The  review  shall  be  conducted  again  before  the  award  of  a 
system  development  and  demonstration  contract  for  the  weapon  or  weapon  system  and  before 
the  award  of  the  initial  production  contract.  Files  shall  be  kept  permanently.  Additionally,  legal 
reviews  of  new,  advanced  or  emerging  technologies  that  may  lead  to  development  of  weapons  or 
weapon  systems  are  encouraged. 

4.7.3. 1 .5.  DoD  Components  shall  not  award  a  contract  for  the  acquisition  of  a 
mission-critical  or  mission  essential  IT  system,  at  any  level,  until  (1)  the  Component  registers  the 
system  with  the  DoD  Chief  Information  Officer  (CIO),  (2)  the  DoD  CIO  determines  the  system 
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has  an  appropriate  information  assurance  strategy,  and  (3)  the  Component  CIO  confirms  that  the 
system  is  being  developed  in  accordance  with  the  Clinger-Cohen  Act  (CCA)  (reference  (m))  by 
complying  with  subparagraph  4.7.3. 2. 3. 2  below.  The  DoD  CIO  will  review  the  Component 
CIO’s  determination  of  CCA  compliance  for  sufficiency  before  contract  award,  for  MDAPs  and 
MAIS  programs.  For  mission-critical  or  mission  essential  IT  systems  being  acquired  under 
MDAPs  and  MAIS  programs,  the  information  assurance  strategy  shall  be  submitted  to  the  DoD 
CIO  for  review.  For  contracts  for  other  than  MDAP  or  MAIS  programs,  the  DoD  CIO’s 
determination  that  the  information  assurance  strategy  is  appropriate  will  generally  be  based  on 
the  certification  of  the  Component  CIO.  Howeveer,  even  if  a  certification  has  been  provided,  the 
DoD  CIO  may  conduct  a  more  detailed  review  of  such  information  assurance  strategies. 

4.7.3. 1.6  IT  intended  for  use  by  non-military  users  shall  be  accessible  to  people 
with  disabilities  (reference  (v)). 

4.7.3.2.  Begin  Development  and  Develop  and  Demonstrate  Systems 

Figure  F4. 
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4.7.3.2.I.  General 

4.7.3.2. 1.1.  The  purpose  of  the  System  Development  and  Demonstration 
phase  is  to  develop  a  system,  reduce  program  risk,  ensure  operational  supportability,  design  for 
producibility,  ensure  affordability,  ensure  protection  of  Critical  Program  Information,  and 
demonstrate  system  integration,  interoperability,  and  utility.  Discovery  and  development  are 
aided  by  the  use  of  simulation-based  acquisition  and  test  and  evaluation  and  guided  by  a  system 
acquisition  strategy  and  test  and  evaluation  master  plan  (TEMP).  System  modeling,  simulation, 
test,  and  evaluation  activities  shall  be  integrated  into  an  efficient  continuum  planned  and 
executed  by  a  test  and  evaluation  integrated  product  team  (T&E  IPT).  This  continuum  shall 
feature  coordinated  test  events,  access  to  all  test  data  by  all  involved  Agencies,  and  independent 
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evaluation  of  test  results  by  involved  Agencies.  Modeling,  simulation,  and  development  test 
shall  be  under  the  direct  responsibility  of  the  PM  or  a  designated  test  agency.  All  results  of  early 
operational  assessments  shall  be  reported  to  the  Service  Chief  by  the  appropriate  operational  test 
activity  and  used  by  the  MDA  in  support  of  decisions.  The  independent  planning,  execution,  and 
evaluation  of  dedicated  Initial  Operational  Test  and  Evaluation  (IOT&E),  as  required  by  law,  and 
Follow-on  Operational  Test  and  Evaluation  (FOT&E),  if  required,  shall  be  the  responsibility  of 
the  appropriate  operational  test  activity  (OTA). 

4.7.3.2. 1 .2.  This  phase  can  be  entered  either  directly  out  of  technology 
opportunity  and  user  need  activities  or  from  Concept  Exploration.  The  actual  entry  point 
depends  on  the  maturity  of  the  technologies,  validated  requirements  (including  urgency  of  need), 
and  affordability.  The  MDA  shall  determine  the  appropriate  entrance  point,  which  shall  be 
Milestone  B.  There  shall  be  only  one  Milestone  B  per  program,  or  evolutionary  block. 

4.7.3.2.1.3.  Each  DoD  Component  should  maintain  a  transition  fund  in  the 
out-years  of  the  Fiscal  Year  Defense  Program  (FYDP)  to  allow  rapid  transition  of  military  or 
commercial  projects  from  technology  opportunity  and  user  needs  activities  to  System 
Development  and  Demonstration  or  Commitment  to  Low-Rate  Production.  Each  DoD 
Component  shall  determine  the  size  of  its  transition  fund.  The  transition  fund  for  the  first  year  of 
the  program  must  be  distributed  to  individual  budget  lines  prior  to  submission  of  the  Budget 
Estimate  Submission  for  that  year. 

4.7.3.2.2.  Entrance  Criteria 

4.7.3.2.2.1.  Entrance  into  System  Development  and  Demonstration  is 
dependent  on  three  things:  technology  (including  software)  maturity,  validated  requirements, 
and  funding.  Unless  some  other  factor  is  overriding  in  its  impact,  the  maturity  of  the  technology 
will  determine  the  path  to  be  followed.  Programs  that  enter  the  process  at  Milestone  B  shall  have 
a  system  architecture  and  an  operational  architecture  for  their  relevant  mission  area. 

4.7.3.2.2.2.  Technology  is  developed  in  S&T  or  procured  from  industry. 
Technology  must  have  been  demonstrated  in  a  relevant  environment  (reference  (c)  for  a 
discussion  of  technology  maturity)  or,  preferably,  in  an  operational  environment  (using  the 
transition  mechanisms)  to  be  considered  mature  enough  to  use  for  product  development  in 
systems  integration.  If  technology  is  not  mature,  the  DoD  Component  shall  use  alternative 
technology  that  is  mature  and  that  can  meet  the  user's  needs.  The  determination  of  technology 
maturity  is  made  by  the  DoD  Component  S&T  Executive,  with  review  of  the  determination  for 
MDAPs  by  the  DUSD(S&T).  If  the  DUSD(S&T)  does  not  concur  with  the  determination,  the 
DUSD(S&T)  will  direct  an  independent  assessment.  To  promote  increased  consideration  of 
technological  issues  early  in  the  development  process,  the  MDA  shall,  at  each  acquisition 
program  decision,  consider  any  position  paper  prepared  by  a  Defense  research  facility  on  a 
technological  issue  relating  to  the  major  system  being  reviewed;  and  any  technological 
assessment  made  by  a  Defense  research  facility  (reference  (w)).  A  defense  research  facility  is  a 
DoD  facility  that  performs  or  contracts  for  the  performance  of  basic  research  or  applied  research 
known  as  exploratory  development. 
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4.7.3.2.2.3.  Prior  to  entering  System  Development  and  Demonstration,  there 
shall  be  an  ORD  validated  by  the  requirements  authority.  The  ORD  contains  operational 
performance  requirements  and  addresses  cost  for  a  proposed  concept  or  system.  Time-phased 
ORDs  must  be  validated  by  the  requirements  authority  prior  to  program  approval.  If  a  mature 
technology,  non-developmental  item,  or  commercial  item  is  being  considered  for  transition  to  an 
acquisition  program  at  Milestone  B  or  C,  it  must  have  a  validated  ORD  prior  to  being  approved 
as  an  acquisition  program. 

4.7.3. 2.2.4.  The  affordability  determination  is  made  in  the  process  of 
addressing  cost  as  a  military  requirement  in  the  requirements  process  and  included  in  each  ORD, 
beginning  with  the  acquisition  cost  but  using  life-cycle  cost  or  total  ownership  cost  where 
available  and  approved.  Transition  into  System  Development  and  Demonstration  also  requires 
full  funding  (i.e.,  inclusion  in  the  budget  and  out-year  program  of  the  funding  for  all  current  and 
future  efforts  necessary  to  carry  out  the  acquisition  strategy),  which  shall  be  programmed  when  a 
system  concept  and  design  have  been  selected,  a  PM  has  been  assigned,  an  ORD  has  been 
approved,  and  system-level  development  is  ready  to  begin.  In  the  case  of  a  replacement  system, 
when  the  Milestone  B  is  projected  to  occur  in  the  first  2  years  of  the  FYDP  under  review,  the 
program  shall  be  fully  funded  in  that  PPBS  cycle.  In  no  case  shall  full  funding  be  done  later  than 
Milestone  B,  unless  a  program  first  enters  the  acquisition  process  at  Milestone  C.  DoD 
Components  shall  fully  fund  their  share  of  approved  joint  and  international  cooperative  program 
commitments. 


4. 7. 3.2. 2. 5.  If  Critical  Program  Information  is  identified  during  non-systems 
acquisition  activities,  the  Component  shall  prepare  preliminary  security  and  foreign  disclosure 
plans  and  anti-tampering  assessments  for  MDA  approval.  These  plans  and  assessments  shall  be 
drawn  from  the  Program  Protection  Plan  (i.e.,  a  comprehensive  plan  to  safeguard  critical 
program  and  technology  information  that  is  associated  with  a  defense  acquisition  program)  and 
addressed  in  the  acquisition  strategy.  The  level  and  detail  of  information  in  the  Plan  will  vary 
based  on  the  criticality  of  the  program,  the  CPI,  and  the  phase  of  the  acquisition  process.  Anti¬ 
tampering  will  be  addressed  in  an  annex  to  the  Plan. 

4.7.3.2.3.  Milestone  B.  Milestone  B  is  normally  the  initiation  of  an  acquisition 
program.  The  purpose  of  Milestone  B  is  to  authorize  entry  into  System  Development  and 
Demonstration. 


4.7.3.2.3.I.  Milestone  Approval  Considerations 

4.7.3.2.3.I.I.  Prior  to  approving  entry  into  System  Development  and 
Demonstration  at  Milestone  B,  the  MDA  shall  consider  the  validated  ORD,  System  Threat 
Assessment,  independent  technology  assessment  and  any  technology  issues  identified  by  DoD 
research  facilities,  any  early  operational  assessments  or  test  and  evaluation  results,  analysis  of 
alternatives  including  compliance  with  the  Department  of  Defense's  strategic  plan  (based  on  the 
Government  Performance  and  Results  Act  (GPRA),  reference  (x)),  the  independent  cost  estimate 
or,  for  MAISs,  component  cost  analysis  and  the  economic  analysis,  manpower  estimate  (if 
applicable),  whether  an  application  for  frequency  allocation  has  been  made  (if  the  system  will 
require  utilization  of  the  electromagnetic  spectrum),  system  affordability  and  funding,  the 
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program  protection  for  Critical  Program  Information,  anti-tamper  provisions,  the  Delegation  of 
Disclosure  Authority  Letter  (DDL)  concerning  foreign  disclosure  of  program  information  vis-a- 
vis  foreign  participation  in  the  program  and/or  sales  of  the  system,  the  proposed  acquisition 
strategy,  cooperative  opportunities,  and  infrastructure  and  operational  support. 

4.7.3. 2.3. 1.2.  At  Milestone  B  the  MDA  shall  confirm  the  acquisition 
strategy  approved  prior  to  release  of  the  final  Request  for  Proposal  and  approve  the  development 
acquisition  program  baseline,  low-rate  initial  production  quantities  (where  applicable),  and 
System  Development  and  Demonstration  exit  criteria  (and  exit  criteria  for  interim  progress 
review,  if  necessary).  For  shipbuilding  programs,  the  lead  ship  engineering  development  model 
shall  be  authorized  at  Milestone  B.  Critical  systems  for  the  lead  and  follow  ships  shall  be 
demonstrated  given  the  level  of  technology  maturity  and  the  associated  risk  prior  to  ship 
installation.  Follow  ships  may  be  initially  authorized  at  Milestone  B,  to  preserve  the  production 
base,  with  final  authorization  dependent  on  completion  of  critical  systems  demonstration,  as 
directed  by  the  MDA. 


4.7.3.2.3.1.3.  The  DOT&E  and  the  cognizant  Overarching  Integrated 
Product  Team  Leader  shall  approve  the  Test  and  Evaluation  Master  Plan  (TEMP)  (including  the 
LFT&E  strategy,  if  applicable)  for  all  OSD  test  and  evaluation  oversight  programs.  If  full-up, 
system-level  LFT&E  is  unreasonably  expensive  and  impractical,  a  waiver  shall  be  approved  by 
the  USD(AT&L),  for  programs  where  he  or  she  is  the  MDA,  or  by  the  CAE,  for  programs  where 
he  or  she  is  the  MDA,  and  an  alternative  LFT&E  plan  shall  be  approved  by  the  DOT&E  before 
entry  into  System  Development  and  Demonstration  (reference  (y). 

4.7.3 .2.3. 1.4.  For  MDAPs,  a  Milestone  B  decision  shall  be  the  occasion 
for  submission  of  a  revised  Selected  Acquisition  Report  (DoD  5000.2-R,  reference  (h)).  IT 
intended  for  use  by  non-military  users  shall  be  accessible  to  people  with  disabilities  (reference 

(v». 


4.7.3.2.3.I.5.  The  tables  in  enclosure  3  identify  the  statutory  and 
regulatory  requirements  that  must  be  met  at  this  milestone.  Note  that  these  cannot  be  deferred  to 
a  follow-on  interim  progress  review  or  future  milestone. 

4.7.3.2.3.2.  IT-Specific  Considerations 

4.7.3.2.3.2.I.  The  MDA  shall  not  approve  program  initiation  or  entry  into 
any  phase  that  requires  milestone  approval  (to  include  full-rate  production)  for  an  acquisition 
program  (at  any  level)  for  a  mission-critical  or  mission-essential  IT  system  until  the  Component 
CIO  confirms  that  the  system  is  being  developed  in  accordance  with  the  Clinger-Cohen  Act 
(CCA)  (reference  (m)).  At  a  minimum,  the  Component  CIO’s  confirmation  shall  include  a 
written  description  of  the  following: 

4.7.3.2.3.2.L1.  The  acquisition  supports  core,  priority  functions  that 
need  to  be  performed  by  the  Federal  Government. 
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4.7.3.2.3.2.1 .2.  No  private  sector  or  government  source  can  better 

support  the  function. 


4.7.3.2.3.2.1 .3.  The  processes  that  the  system  supports  have  been 
redesigned  to  reduce  costs,  improve  effectiveness  and  maximize  the  use  of  COTS  technology. 

4.7. 3.2.3 .2. 1.4.  An  analysis  of  alternatives  has  been  conducted. 

4.7.3.2.3.2.1.5.  For  A1S,  an  economic  analysis  has  been  conducted 
that  includes  a  calculation  of  the  return  on  investment;  or  for  non-AIS  programs,  an  LCCE  has 
been  conducted. 


4.7.3.2.3.2.1.6.  There  are  clearly  established  measures  and 
accountability  for  program  progress. 

4.7. 3.2.3. 2. 1.7.  Mission-related,  outcome-based  performance 
measures  have  been  established  and  linked  to  strategic  goals. 

4.7.3 .2.3.2. 1.8.  The  program  has  an  information  assurance  strategy 
that  is  consistent  with  DoD  policies,  standards,  and  architectures. 

4.7.3.2.3.2.1.9.  The  acquisition  is  consistent  with  the  Global 
Information  Grid  policies  and  architecture,  to  include  relevant  standards. 

4.7.3.23.2. 1.10.  To  the  maximum  extent  practicable,  (1)  modular 
contracting  is  being  used,  and  (2)  the  program  is  being  implemented  in  phased,  successive 
blocks,  each  of  which  meets  part  of  the  mission  need  and  delivers  a  measurable  benefit, 
independent  of  future  blocks. 

4.7.3.23.2. 1.1 1.  The  system  being  acquired  is  registered  with  the 
DoD  CIO  (see  5000.2-R,  Appendix  G). 

4.73.23.2.2.  For  MDAP  programs,  the  Component  CIO’s  confirmation 
shall  be  provided  to  both  the  DoD  CIO  and  the  MDA. 

4.73.23.23.  For  MAIS  programs,  the  certification  shall  be  submitted  to 
the  DoD  CIO  and  will  include  a  CCA  Compliance  Report  that  addresses  the  above  items.  The 
DoD  CIO  will  review  the  CCA  Compliance  Report  and  certify  to  the  congressional  defense 
committees  that  the  MAIS  is  being  developed  in  accordance  with  the  CCA  before  approving 
program  initiation  or  entry  into  any  phase  (including  full-rate  production)  that  requires  a 
milestone  approval,  as  required  by  Sec.  8102of  the  FY  2001  Appropriations  Act  (reference  u). 
For  delegated  MAIS  programs,  the  MDA  shall  not  approve  program  initiation  or  entry  into  any 
phase  that  requires  milestone  approval  (including  full-rate  production)  until  the  DoD  CIO 
certifies  CCA  compliance  to  the  congressional  defense  committees.  The  DoD  CIO  will  issue 
guidance  on  procedures  for  submitting  CCA  compliance  reports  for  MAIS.  The  CCA 
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Compliance  Report  shall  be  submitted  at  least  three  months  before  the  milestone  approval  is 
needed. 


4.7.3.23.2.4.  The  requirement  to  confirm  CCA  compliance  applies  to 
milestone  decisions  for  each  block  of  an  evolutionary  acquisition.  The  requirements  of  the  CCA 
apply  to  all  IT  (including  NSS)  acquisitions,  but  the  CCA  confirmation  requirements  described 
above  apply  only  to  mission  critical  and  mission  essential  IT  systems.  For  purposes  of  CAA 
certification  (as  required  by  Section  8102  of  the  FY  2001  DoD  Appropriations  Act  (reference 
u)),  all  MAIS  shall  be  considered  mission  critical  or  mission  essential.  The  CCA  certification 
requirement  applies  only  to  MAIS. 

4.7.3.2.33.  Acquisition  Strategy  Considerations 

4.73.2.33.1.  The  acquisition  strategy  shall  define  not  only  the  approach 
to  be  followed  in  System  Development  and  Demonstration,  but  also  how  the  program  is 
structured  to  achieve  full  capability.  There  are  two  such  approaches,  evolutionary  and  single 
step  to  full  capability.  An  evolutionary  approach  is  preferred.  Evolutionary  acquisition  is  an 
approach  that  fields  an  operationally  usefUl  and  supportable  capability  in  as  short  a  time  as 
possible.  This  approach  is  particularly  useful  if  software  is  a  key  component  of  the  system,  and 
the  software  is  required  for  the  system  to  achieve  its  intended  mission.  Evolutionary  acquisition 
delivers  an  initial  capability  with  the  explicit  intent  of  delivering  improved  or  updated  capability 
in  the  future. 


4.73.2.3.3.2.  The  approach  to  be  followed  depends  on  the  availability  of 
time-phased  requirements  in  the  ORD,  the  maturity  of  technologies,  the  relative  costs  and 
benefits  of  executing  the  program  in  blocks  versus  a  single  step,  including  consideration  of  how 
best  to  support  each  block  when  fielded  (e.g.,  whether  to  retrofit  earlier  blocks,  the  cost  of 
multiple  configurations,  how  best  to  conduct  new  equipment  training,  etc.).  The  rationale  for 
choosing  a  single  step  to  full  capability,  when  given  an  ORD  with  time-phased  requirements, 
shall  be  addressed  in  the  acquisition  strategy.  Similarly,  the  rationale  for  choosing  an 
evolutionary  approach,  when  given  an  ORD  with  no  time-phased  requirements,  shall  be 
addressed  in  the  acquisition  strategy.  For  both  the  evolutionary  and  single-step  approaches, 
software  development  and  integration  shall  follow  an  iterative  spiral  development  process  in 
which  continually  expanding  software  versions  are  based  on  learning  from  earlier  development. 

4.73.2333.  In  an  evolutionary  approach,  the  ultimate  capability 
delivered  to  the  user  is  divided  into  two  or  more  blocks,  with  increasing  increments  of  capability. 
Deliveries  for  each  block  may  extend  over  months  or  years.  Block  1  provides  the  initial 
deployment  capability  (a  usable  increment  of  capability  called  for  in  the  ORD).  There  are  two 
approaches  to  treatment  of  subsequent  blocks: 

4.7.3.2333.1.  The  ORD  includes  a  firm  definition  of  full  capability, 
as  well  as  a  firm  definition  of  requirements  to  be  satisfied  by  each  block,  including  an  IOC  date 
for  each  block.  In  this  case,  each  block  shall  be  baselined  and  the  acquisition  strategy  shall 
define  each  block  of  capability  and  how  it  will  be  funded,  developed,  tested,  produced,  and 
operationally  supported. 
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4.7.3.2.3.3.3.2.  The  ORD  includes  a  firm  definition  of  the  first  block, 
but  does  not  allocate  to  specific  subsequent  blocks  the  remaining  requirements  that  must  be  met 
to  achieve  full  capability.  In  an  evolutionary  acquisition,  the  specific  requirements  for  Block  2 
are  defined  in  the  ORD,  based  on  the  user's  increased  understanding  of  the  delivered  capability, 
the  evolving  threat,  and  available  technology,  lead-time-away  from  beginning  work  on  Block  2, 
and  so  on,  until  full  capability  is  achieved.  Requirements  that  cannot  be  fulfilled  during  a 
specific  block  development,  with  the  approval  of  the  requirements  authority,  may  be  delayed  to 
the  next  block  development.  The  first  block,  and  each  subsequent  block,  is  baselined  in 
conjunction  with  the  MDA  authorizing  work  to  proceed  on  that  block.  The  acquisition  strategy 
shall  define  the  first  block,  of  capability,  and  how  it  will  be  funded,  developed,  tested,  produced, 
and  supported;  the  full  capability  the  evolutionary  acquisition  is  intended  to  satisfy,  and  the 
funding  and  schedule  planned  to  achieve  the  full  capability  to  the  extent  it  can  be  described;  and 
the  management  approach  to  be  used  to  define  the  requirements  for  each  subsequent  block  and 
the  acquisition  strategy  applicable  to  each  block,  including  whether  end  items  delivered  under 
earlier  blocks  will  be  retrofitted  with  later  block  improvements. 

4.7.3.2.3.3.4.  In  a  single  step  to  full  capability  approach,  the  full  system 
capability  is  developed  and  demonstrated  prior  to  Milestone  C.  Under  this  approach,  any 
modification  that  is  of  sufficient  cost  and  complexity  that  it  could  itself  qualify  as  an  MDAP  or 
MAIS  shall  be  considered  for  management  purposes  as  a  separate  acquisition  effort. 
Modifications  that  do  not  cross  the  MDAP  or  MAIS  threshold  shall  be  considered  part  of  the 
program  being  modified,  unless  the  program  is  no  longer  in  production.  In  that  case,  the 
modification  shall  be  considered  a  separate  acquisition  effort.  Modifications  may  cause  a 
program  baseline  deviation.  Deviations  shall  be  reported  using  the  criteria  and  procedures  in 
DoD  5000.2-R  (reference  (h)). 

4.7.3.23.4.  Entry  into  System  Development  and  Demonstration 

4.73.2.3.4.1.  Milestone  B  approval  can  lead  to  System  Integration  or 
System  Demonstration.  Regardless  of  the  approach  recommended,  PMs  and  other  acquisition 
managers  shall  continually  assess  program  risks.  Risks  must  be  well  understood,  and  risk 
management  approaches  developed,  before  decision  authorities  can  authorize  a  program  to 
proceed  into  the  next  phase  of  the  acquisition  process.  Risk  management  is  an  organized  method 
of  identifying  and  measuring  risk  and  developing,  selecting,  and  managing  options  for  handling 
these  risks.  The  types  of  risk  include,  but  are  not  limited  to,  schedule,  cost,  technical  feasibility, 
threat,  risk  of  technical  obsolescence,  security,  software  management,  dependencies  between  a 
new  program  and  other  programs,  and  risk  of  creating  a  monopoly  for  future  procurements. 

4.73.23.4.2.  The  nature  of  software-intensive  system  development, 
characterized  by  a  spiral  build-test-fix-test-deploy  process,  may  lend  itself  to  a  combined  system 
integration  and  system  demonstration,  rather  than  serial  efforts  more  typical  of  hardware¬ 
intensive  systems. 

4.73.2.4.  System  Integration 
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4.7.3.2.4.1.  The  program  shall  enter  System  Integration  when  the  PM  has  an 
architecture  for  the  system,  but  has  not  yet  integrated  the  subsystems  into  a  complete  system. 

The  program  shall  exit  System  Integration  when  the  integration  of  the  system  has  been 
demonstrated  in  a  relevant  environment  using  prototypes  (e.g.,  first  flight,  interoperable  data 
flow  across  systems),  a  system  configuration  has  been  documented,  the  MDA  determines  a 
factor  other  than  technology  justifies  forward  progress,  or  the  MDA  decides  to  end  this  effort. 

4.7.3. 2.4.2.  This  effort  is  intended  to  integrate  the  subsystems  and  reduce 
system-level  risk.  The  work  effort  will  be  guided  by  a  validated  ORD.  The  work  effort  will  be 
followed  by  System  Demonstration  after  a  successful  Interim  Progress  Review  by  the  MDA  (or 
the  person  designated  by  the  MDA). 

4.7.3.2.5.  Interim  Progress  Review.  The  purpose  of  an  interim  progress  review  is 
to  confirm  that  the  program  is  progressing  within  the  phase  as  planned  or  to  adjust  the  plan  to 
better  accommodate  progress  made  to  date,  changed  circumstances,  or  both.  If  the  adjustment 
involves  changing  the  acquisition  strategy,  the  change  must  be  approved  by  the  MDA.  There  is 
no  required  information  necessary  for  this  review  other  than  the  information  specifically 
requested  by  the  decision-maker. 

4.7.3.2.6.  System  Demonstration 

4.7.3. 2. 6. 1 .  The  program  shall  enter  System  Demonstration  when  the  PM  has 
demonstrated  the  system  in  prototype  articles.  This  effort  is  intended  to  demonstrate  the  ability 
of  the  system  to  operate  in  a  useful  way  consistent  with  the  validated  ORD. 

4.7.3. 2.6.2.  This  phase  ends  when  a  system  is  demonstrated  in  its  intended 
environment,  using  engineering  development  models  or  integrated  commercial  items;  meets 
validated  requirements;  industrial  capabilities  are  reasonably  available;  and  the  system  meets  or 
exceeds  exit  criteria  and  Milestone  C  entrance  requirements.  Preference  shall  be  given  to  the  use 
of  modeling  and  simulation  as  the  primary  method  for  assessing  product  maturity  where  proven 
capabilities  exist,  with  the  use  of  test  to  validate  modeling  and  simulation  results.  The 
completion  of  this  phase  is  dependent  on  a  decision  by  the  MDA  to  commit  to  the  program  at 
Milestone  C  or  a  decision  to  end  this  effort. 

4.7.3. 3.  Commitment  to  Low-Rate  Production  and  Produce  and  Deploy  Systems 
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Figure  F5. 
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4.7.3. 3.1.  General 


4.7.3.3.1.1.  The  purpose  ofthe  Production  and  Deployment  phase  is  to 
achieve  an  operational  capability  that  satisfies  mission  needs.  The  production  requirement  of 
this  phase  does  not  apply  to  MAISs.  However,  software  has  to  prove  its  maturity  level  prior  to 
deploying  to  the  operational  environment.  Once  maturity  has  been  proven,  the  system  or  block 
is  baselined,  and  a  methodical  and  synchronized  deployment  plan  is  implemented  to  all 
applicable  locations. 

4.7.3 .3. 1.2.  A  system  must  be  demonstrated  before  the  Department  of 
Defense  will  commit  to  production  (or  procurement)  and  deployment.  For  DOT&E  Oversight 
programs,  a  system  can  not  be  produced  at  full-rate  until  a  Beyond  Low-Rate  Initial  Production 
Report  has  been  completed  and  sent  to  Congress,  the  Secretary  of  Defense,  and  the 
USD(AT&L).  The  MDA  shall  make  the  commitment  decision  at  Milestone  C.  Milestone  C  can 
be  reached  directly  from  pre-systems  acquisition  (e.g.,  a  commercial  product)  or  from  System 
Development  and  Demonstration  phase. 

4.7.3. 3.2.  Entrance  Criteria.  Regardless  of  the  entry  point,  approval  at  Milestone 
C  is  dependent  on  the  following  criteria  being  met  (or  a  decision  by  the  MDA  to  proceed): 

4.7.3. 3. 2.1.  Technology  maturity  (with  an  independent  technology  readiness 
assessment),  system  and  relevant  mission  area  (operational)  architectures,  mature  software 
capability,  demonstrated  system  integration  or  demonstrated  commercial  products  in  a  relevant 
environment,  and  no  significant  manufacturing  risks. 

4.7.33.2.2.  An  approved  ORD. 
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4.7.3.3.2.3.  Acceptable  interoperability. 

4.7.3.3.2.4.  Acceptable  operational  supportability. 

4.7.3.3.2.5.  Compliance  with  the  DoD  Strategic  Plan  (reference(z)). 

4.7.33.2.6.  Demonstration  that  the  system  is  affordable  throughout  the  life 
cycle,  optimally  funded,  and  properly  phased  for  rapid  acquisition. 

4.73.3.2.7.  Acceptable  information  assurance  to  include  information 
assurance  detection  and  recovery. 

4.733.2. 8.  Acceptable  anti-tamper  provisions. 

4.7.3 .3.3.  Milestone  C.  The  purpose  of  this  milestone  is  to  authorize  entry  into 
low-rate  initial  production  (for  MDAPs  and  major  systems),  into  production  or  procurement  (for 
non-major  systems  that  do  not  require  low-rate  production)  or  into  limited  deployment  for  MAIS 
or  software-intensive  systems  with  no  production  components. 


4.7333.1.  Milestone  Approval  Considerations 


4.7333.1.1.  Prior  to  making  the  milestone  decision,  the  MDA  shall 
consider  the  independent  cost  estimate,  and,  for  MAISs,  the  component  cost  analysis  and 
economic  analysis  ,  the  manpower  estimate,  compliance  with  the  CCA  (reference  (m)),  whether 
an  application  for  frequency  allocation  has  been  approved  (for  systems  that  require  utilization  of 
the  electromagnetic  spectrum).  System  Threat  Assessment,  the  program  protection  for  Critical 
Program  Information  including  anti-tamper  recommendations,  the  DDL,  and  an  established 
completion  schedule  for  National  Environmental  Policy  Act  (NEPA)  (reference  (aa))  compliance 
covering  testing,  training,  basing,  and  operational  support. 


4.7333.1.2.  At  this  milestone,  the  MDA  shall  confirm  the  acquisition 
strategy  approved  prior  to  the  release  of  the  final  Request  for  Proposal  and  approve  an  updated 
development  acquisition  program  baseline,  exit  criteria  for  low-rate  initial  production  (LRIP)  (if 
needed)  or  limited  deployment,  and  the  acquisition  decision  memorandum. 


4.7.333.13.  The  DOT&E  and  cognizant  OIPT  Leader  shall  approve  the 
TEMP  for  all  OSD  test  and  evaluation  oversight  programs.  For  MDAPs,  a  milestone  decision 
shall  be  the  occasion  for  submission  of  a  revised  Selected  Acquisition  Report  (reference  (c)). 


4.7333.1.4.  A  favorable  Milestone  C  decision  authorizes  the  PM  to 
commence  LRIP  or  limited  deployment  for  MDAPs  and  major  systems.  The  PM  is  only 
authorized  to  commence  full-rate  production  with  further  approval  of  the  MDA.  There  shall  be 
normally  no  more  than  one  decision  (i.e.,  either  low-rate  or  full-rate)  at  the  Defense  Acquisition 
Executive  (DAE)-level  for  MDAPs. 
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4.7.3.33. 1.5.  The  tables  at  enclosure  3  identify  the  statutory  and 
regulatory  requirements  that  must  be  met  at  this  decision  point. 

4.73.3.3.2.  IT-Specific  Considerations 

4.7333.2.1.  For  MAIS,  the  MDA  shall  approve,  in  coordination  with 
DOT&E,  the  quantity  and  location  of  sites  for  a  limited  deployment  for  IOT&E. 

4.7333.2.2.  See  paragraph  4.73.23.2  for  the  requirement  to  certify  CCA 
compliance  before  entering  Production  and  Deployment. 

4.733.4.  Low-Rate  Initial  Production  (LRIP) 

4.7.33.4.1 .  This  work  effort  is  intended  to  result  in  completion  of 
manufacturing  development  in  order  to  ensure  adequate  and  efficient  manufacturing  capability 
and  to  produce  the  minimum  quantity  necessary  to  provide  production  configured  or 
representative  articles  for  initial  operational  test  and  evaluation  (IOT&E),  establish  an  initial 
production  base  for  the  system;  and  permit  an  orderly  increase  in  the  production  rate  for  the 
system,  sufficient  to  lead  to  full-rate  production  upon  successful  completion  of  operational  (and 
live-fire,  where  applicable)  testing.  The  work  shall  be  guided  by  the  ORD. 

4.733.4.2.  Deficiencies  encountered  in  testing  prior  to  Milestone  C  shall  be 
resolved  prior  to  proceeding  beyond  LRIP  (at  the  Full-Rate  Production  Decision  Review)  and 
any  fixes  verified  in  IOT&E.  Operational  test  plans  shall  be  provided  to  the  DOT&E  for 
oversight  programs  in  advance  of  the  start  of  operational  test  and  evaluation. 

4.733.43.  LRIP  may  be  funded  by  either  research,  development,  test  and 
evaluation  appropriation  (RDT&E)  or  by  procurement  appropriations,  depending  on  the  intended 
usage  of  the  LRIP  assets.  The  DoD  Financial  Management  Regulation  (reference  (bb))  provides 
specific  guidance  for  determining  whether  LRIP  should  be  budgeted  in  RDT&E  or  in 
procurement  appropriations. 

4.733.4.4.  LRIP  quantities  shall  be  minimized.  The  MDA  shall  determine 
the  LRIP  quantity  for  MDAPs  and  major  systems  at  Milestone  B.  The  LRIP  quantity  (with 
rationale  for  quantities  exceeding  10  percent  of  the  total  production  quantity  documented  in  the 
acquisition  strategy)  shall  be  included  in  the  first  Selected  Acquisition  Report  (reference  (c)) 
after  its  determination.  Any  increase  in  quantity  after  the  initial  determination  shall  be  approved 
by  the  MDA.  The  LRIP  quantity  shall  not  be  less  than  one  unit.  When  approved  LRIP 
quantities  are  expected  to  be  exceeded  because  the  program  has  not  yet  demonstrated  readiness 
to  proceed  to  full-rate  production,  the  MDA  shall  assess  the  cost  and  benefits  of  a  break  in 
production  versus  continuing  annual  buys. 

4.733.4.5.  DOT&E  shall  determine  the  number  of  LRIP  articles  required  for 
LFT&E  and  IOT&E  of  DOT&E  Oversight  Programs  (MDAPs  as  defined  in  paragraph  a(2)(B)  of 
10  U.S.C.  139  (reference  (cc)).  For  a  system  that  is  not  a  DOT&E  Oversight  Program,  the 
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Operational  Test  and  Evaluation  Agency  shall  determine  the  number  of  LRIP  articles  required 
for  IOT&E. 


4.7.33.4.6.  LRIP  is  not  applicable  to  AISs  or  software  intensive  systems  with 
no  developmental  hardware.  However,  a  limited  deployment  phase  may  be  applicable. 

4.7.33.4.7.  LRIP  for  ships  and  satellites  is  production  of  items  at  the 
minimum  quantity  and  rate  that  is  feasible  and  that  preserves  the  mobilization  production  base 
for  that  system  (reference  (dd)). 

4.733.5.  Full-Rate  Production  Decision  Review 

4.7.33.5.1.  Before  making  the  full-rate  production  and  deployment  decision, 
the  MDA  shall  consider: 

4.733.5.1.1.  The  independent  cost  estimate,  and  for  MAISs,  the 
component  cost  analysis  and  economic  analysis. 

4.7.3 .3 .5 . 1 .2.  The  manpower  estimate  (if  applicable). 

4.7.33.5.1.3.  The  results  of  operational  and  live  fire  test  and  evaluation 

(if  applicable). 

4.7.33.5.1.4.  CCA  compliance  certification  (reference  (m))  and 
certification  for  MAISs  (reference  (u)). 

4.733.5.1.5.  C4I  supportability  certification. 

4.733.5.1.6.  Interoperability  certification. 

4.7.33.5.2.  The  MDA  shall  confirm  the  acquisition  strategy  approved  prior  to 
the  release  of  the  final  Request  for  Proposal,  the  production  acquisition  program  baseline, 
provisions  for  evaluation  of  post-deployment  performance  (in  accordance  with  GPRA  (reference 
(x)),  CCA  (reference  (m)),  and  the  Paperwork  Reduction  Act  (reference  (ee)),  and  the  acquisition 
decision  memorandum. 

4.733.53.  A  full-rate  production  and  deployment  decision  shall  be  the 
occasion  for  an  update  of  the  Selected  Acquisition  Report  (reference  (c)). 

4.733.6.  Full-Rate  Production  and  Deployment.  Following  IOT&E,  the 
submission  of  the  Beyond  LRIP  and  LFT&E  Reports  (where  applicable)  to  Congress,  the 
Secretary  of  Defense,  and  the  USD(AT&L),  and  the  completion  of  a  Full-Rate  Production 
Decision  Review  by  the  MDA  (or  by  the  person  designated  by  the  MDA),  the  program  shall 
enter  Full-Rate  Production  (or  procurement)  and  Deployment. 
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4.7.4.  Sustainment.  The  objectives  of  this  activity  are  the  execution  of  a  support 
program  that  meets  operational  support  performance  requirements  and  sustainment  of  systems  in 
the  most  cost-effective  manner  for  the  life  cycle  of  the  system.  When  the  system  has  reached  the 
end  of  its  useful  life,  it  must  be  disposed  of  in  an  appropriate  manner. 

Figure  F6. 


Operations  and  Support 
_ W  ork  Content _ 


•  O  peratio  nal  support 


•  D  e  m  ilita  r  Iz  a  tlo  n 

•  D  Is  p  o  s  a  I 


4.7.4. 1.  Sustain  Systems 

4.7.4. 1.1.  The  sustainment  program  includes  all  elements  necessary  to  maintain 
the  readiness  and  operational  capability  of  deployed  systems.  The  scope  of  support  varies 
among  programs  but  generally  includes  supply,  maintenance,  transportation,  sustaining 
engineering,  data  management,  configuration  management,  manpower,  personnel,  training, 
habitability,  survivability,  safety,  occupational  health,  protection  of  Critical  Program  Information 
(CPI),  anti-tamper  provisions,  IT  (including  NSS)  supportability  and  interoperability,  and 
environmental  management  functions.  This  activity  also  includes  the  execution  of  operational 
support  plans  in  peacetime,  crisis,  and  wartime. 

4.7.4. 1.2.  Programs  with  software  components  must  be  capable  of  responding  to 
emerging  requirements  that  will  require  software  modification  or  periodic  enhancements  after  a 
system  is  deployed. 

4.7.4. 1.3.  A  follow-on  operational  test  and  evaluation  program  that  evaluates 
operational  effectiveness,  survivability,  suitability,  and  interoperability,  and  that  identifies 
deficiencies  shall  be  conducted,  as  appropriate  (reference  (c)). 

4.7.4. 1.4.  The  Department  must  develop  a  system  to  assess  customer  confidence 
at  each  step  of  the  requirement  and  distribution  chain.  The  primary  metric  of  confidence  shall  be 
customer  wait  time.  In  order  to  achieve  customer  confidence,  the  system  shall  use  a  simplified 
priority  system  driven  by  user  need  date,  be  integrated  to  allow  total  asset  visibility,  and  use  a 
fully  integrated  data  environment  to  ensure  the  joint  users'  ability  to  make  timely  and  confident 
logistics  decisions. 
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4.7.4.2.  Evolutionary  Sustainment.  Supporting  the  tenets  of  evolutionary  acquisition, 
sustainment  strategies  must  evolve  and  be  refined  throughout  the  life  cycle,  particularly  during 
development  of  subsequent  blocks  of  an  evolutionary  strategy,  modifications,  upgrades,  and 
reprocurement.  The  PM  shall  ensure  that  a  flexible,  performance-oriented  strategy  to  sustain 
systems  is  developed  and  executed.  This  strategy  will  include  consideration  of  the  full  scope  of 
operational  support,  such  as  maintenance,  supply,  transportation,  sustaining  engineering, 
spectrum  supportability,  configuration  and  data  management,  manpower,  training, 
environmental,  health,  safety,  disposal  and  security  factors.  The  use  of  performance 
requirements  or  conversion  to  performance  requirements  shall  be  emphasized  during 
reprocurement  of  systems,  subsystems,  components,  spares,  and  services  after  the  initial 
production  contract. 

4.7.4.3.  Dispose  of  Systems.  At  the  end  of  its  useful  life,  a  system  must  be 
demilitarized  and  disposed.  The  PM  shall  address  in  the  acquisition  strategy  demilitarization  and 
disposal  requirements  and  shall  ensure  that  sufficient  information  exists  so  that  disposal  can  be 
carried  out  in  a  way  that  is  in  accordance  with  all  legal  and  regulatory  requirements  relating  to 
safety,  security,  and  the  environment.  The  Defense  Reutilization  and  Marketing  Office  shall 
execute  the  PM's  strategy  and  demilitarize  and  dispose  of  items  assigned  to  the  Office. 

4.7.5.  Follow-on  Blocks  for  Evolutionary  Acquisition 

Figure  F7. 


BLOCK  3 


4.7.5. 1.  Evolutionary  acquisition  strategies  are  the  preferred  approach  to  satisfying 
operational  needs.  Evolutionary  acquisition  strategies  define,  develop,  test,  and  produce/deploy 
an  initial,  militarily  useful  capability  ("Block  1")  and  plan  for  subsequent  definition, 
development,  test  and  production/deployment  of  increments  beyond  the  initial  capability  over 
time  (Blocks  2,  3,  and  beyond).  The  scope,  performance  capabilities,  and  timing  of  subsequent 
increments  shall  be  based  on  continuous  communications  among  the  requirements,  acquisition, 
intelligence,  logistics,  and  budget  communities.  Acquisition  strategy  considerations  for 
evolutionary  acquisition  are  described  in  subparagraph  4.7.3 .2.3.3.,  above. 

4.7.5.2.  The  requirements  community  shall  ensure  that  user  requirements  are 
prioritized  (and  constrained,  if  necessary)  for  both  the  capability  in  the  initial  block  and  the 
increasing  functionality  in  subsequent  blocks. 
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4.7.53.  The  PM  shall  balance  the  need  to  meet  evolving  user  requirements 
(responsiveness)  against  the  ability  of  the  users  to  support  continued  training  and  repeated 
deployments  for  new  blocks  (turbulence).  The  PM  shall  also  consider  the  ability  of  the  system 
contractors)  to  develop/integrate,  test,  and  deploy  multiple  concurrent  blocks. 

4.8.  Acquisition  Categories  and  Milestone  Decision  Authority.  A  technology  project  or 
acquisition  program  shall  be  categorized  based  on  its  location  in  the  acquisition  process,  dollar 
value,  and  complexity. 

4.8.1.  Pre-ACAT  Technology  Projects.  Advanced  Technology  Demonstrations,  Joint 
Warfighting  Experiments,  Advanced  Concept  and  Technology  Demonstrations,  Concept 
Exploration  are  efforts  that  occur  prior  to  acquisition  program  initiation.  Component  Advanced 
Development  projects  may  occur  before  or  after  acquisition  program  initiation.  If  they  occur 
after  program  initiation,  they  will  be  acquisition  programs.  The  USD(AT&L)  shall  be  the  MDA 
for  those  projects  that,  if  successful,  will  likely  result  in  an  MDAP.  The  ASD(C3I)  shall  be  the 
MDA  for  those  projects  that,  if  successful,  will  result  in  a  MAIS. 

4.8.2.  ACATI 

4.8.2. 1.  ACAT  I  programs  are  those  programs  that  are  MDAPs  or  that  are  designated 
ACAT I  by  the  MDA  as  a  result  of  the  MDA's  special  interest. 

4.8.2.2.  In  some  cases,  an  ACAT  LA  program,  as  defined  below,  also  meets  the 
definition  of  a  MDAP.  The  USD(AT&L)  and  the  ASD(C3I)/DoD  Chief  Information  Officer 
(CIO)  shall  decide  who  will  be  the  MDA  for  such  AIS  programs.  Regardless  of  who  is  the 
MDA,  the  statutory  requirements  that  apply  to  MDAPs  shall  apply  to  such  AIS  programs. 

4.8.23.  ACAT  I  programs  have  two  sub-categories:  ACAT  ID,  for  which  the  MDA 
is  USD(AT&L)  (the  "D"  refers  to  the  Defense  Acquisition  Board  (DAB),  which  advises  the 
USD(AT&L)  at  major  decision  points)  or  ACAT  IC,  for  which  the  MDA  is  the  DoD  Component 
Head  or,  if  delegated,  the  DoD  Component  Acquisition  Executive  (CAE)  (the  "C"  refers  to 
Component). 

4.8.2.4.  Initially,  all  programs  are  treated  as  ACAT  ID  until  formally  designated 
ACAT  IC  by  the  USD(AT&L).  At  any  time,  the  USD(AT&L)  may  delegate  Milestone  Decision 
Authority  of  an  ACAT  I  program  to  the  Head  of  the  DoD  Component  who  may  redelegate  to  the 
CAE. 


4.8.2.5.  If  the  USD(AT&L)  redesignates  a  formerly  ACAT  ID  program  as  an  ACAT 
IC  program,  the  following  direction  shall  apply: 

4.8.2.5.I.  Exit  criteria  established  by  the  USD(AT&L)  prior  to  the  delegation  of 
decision  authority  shall  be  maintained  in  effect  unless  the  USD(AT&L)  concurs  with  any 
changes. 
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4.8.2.5.2.  The  CAE  shall  approve  Acquisition  Program  Baseline  (APB)  changes 
(references  (c)  and  (i)),  including  updates  for  threshold  breaches,  and  provide  a  copy  of  the  new 
APB  to  USD(AT&L). 

4.8.2. 5.3.  Acquisition  strategies,  including  CAIV  objectives  and  LRIP  quantities, 
established  by  the  USD(AT&L)  prior  to  the  delegation  of  decision  authority  shall  be  maintained 
in  effect  during  the  phase  for  which  approval  was  given,  unless  the  USD(AT&L)  concurs  with 
any  changes.  When  the  next  milestone  approaches  and  an  updated  acquisition  strategy  is 
prepared  for  the  next  phase  of  the  ACAT IC  program,  it  shall  not  be  subject  to  USD(AT&L) 
approval. 

48.2.5.4.  The  OSD  Cost  Analysis  Improvement  Group  (CAIG)  shall  not  conduct 
Independent  Cost  Estimates  for  ACAT  IC  programs  unless  specifically  requested  by 
USD(AT&L).  This  request  usually  accompanies  the  designation  of  the  program  as  ACAT  IC.  If 
the  CAIG  does  not  conduct  an  independent  cost  estimate,  the  Component  cost  analysis  office 
shall  provide  a  component  cost  analysis  to  the  CAE  for  consideration  at  the  appropriate  decision 
point. 


4.8.3.  ACATIA 

4.8.3. 1.  ACAT  IA  programs  are  those  programs  that  are  MAISs  or  that  are 
designated  as  ACAT  IA  by  the  MDA  as  a  result  of  the  MDA's  special  interest. 

4.8.3.2.  ACAT  IA  programs  have  two  sub-categories:  ACAT  IAM  for  which  the 
MDA  is  the  Chief  Information  Officer  (CIO)  of  the  Department  of  Defense  (DoD),  the 
ASD(C3I)  (the  "M"  (in  ACAT  IAM)  refers  to  Major  Automated  Information  System  (MAIS))  or 
ACAT  IAC,  for  which  the  DoD  CIO  has  delegated  milestone  decision  authority  to  the  CAE  or 
Component  CIO  (the  "C"  (in  ACAT  IAC)  refers  to  Component). 

4.8.3.3.  The  ASD(C3I)  designates  programs  as  ACAT  IAM  or  ACAT  IAC. 

4.8.3.4.  If  the  ASD(C3I)  redesignates  a  formerly  ACAT  IAM  program  as  an  ACAT 
IAC  program,  the  following  direction  shall  apply: 

4.8.3. 4.1.  Exit  criteria  established  by  the  ASD(C3I)  prior  to  the  delegation  of 
decision  authority  shall  be  maintained  in  effect  unless  the  ASD(C3I)  concurs  with  any  changes. 

4.8.3.4.2.  The  CAE  or  Component  CIO  shall  approve  Acquisition  Program 
Baseline  (APB)  changes,  including  updates  for  threshold  breaches,  and  provide  a  copy  of  the 
new  APB  to  ASD(C3I). 

4.8.3.4.3.  Acquisition  strategies,  including  CAIV  objectives,  established  prior  to 
the  delegation  of  decision  authority  shall  be  maintained  in  effect  during  the  phase  for  which 
approval  was  given,  unless  the  ASD(C3I)  concurs  with  any  changes.  When  the  next  milestone 
approaches  and  an  updated  acquisition  strategy  is  prepared  for  the  next  phase  of  the  ACAT  IAC 
program,  it  shall  not  be  subject  to  ASD(C3I)  approval. 
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4.8.4.  ACAT II.  ACAT II  programs  are  those  programs  that  do  not  meet  the  criteria  for 
an  ACAT  I  program,  but  that  are  Major  Systems  or  that  are  designated  as  ACAT  II  by  the  MDA 
as  a  result  of  the  MDA's  special  interest.  Because  of  the  dollar  values  of  MAISs,  no  AIS 
programs  are  ACAT  II.  The  MDA  is  the  CAE  or  the  individual  designated  by  the  CAE. 

4.8.5.  ACAT  III  ACAT  III  programs  are  defined  as  those  acquisition  programs  that  do 
not  meet  the  criteria  for  an  ACAT  I,  an  ACAT  IA,  or  an  ACAT  II.  The  MDA  is  designated  by 
the  CAE  and  shall  be  at  the  lowest  appropriate  level.  This  category  includes  less-than-major 
AISs. 


4.8.6.  Changes  in  ACAT  Level 

4.8.6. 1.  The  DoD  Component  is  responsible  for  notifying  the  USD(AT&L)  or 
ASD(C3I)  when  cost  growth  or  a  change  in  acquisition  strategy  results  in  reclassifying  a 
formerly  lower  ACAT  program  as  an  ACAT  I  or  IA  program.  ACAT-level  changes  will  be 
reported  as  soon  as  the  Component  suspects,  within  reasonable  confidence,  that  the  program  is 
within  10  percent  encroachment  of  the  next  ACAT  level.  ACAT-level  reclassification  will  occur 
upon  designation  of  the  USD(AT&L)  or  the  ASD(C3I). 

4.8.6.2.  The  CAE  shall  request  in  writing  a  reclassification  of  an  ACAT  I  or  IA 
program  to  a  lower  acquisition  category.  The  request  shall  identify  the  reasons  for  the  reduction 
in  category.  The  category  reduction  will  become  effective  upon  approval  of  the  request  by  the 
USD(AT&L)  or  ASD(C3I). 

4.8.6.3.  The  USD(AT&L)  or  ASD(C3I)  may  reclassify  an  acquisition  program  as 
ACAT  ID  or  IAM  at  any  time. 

4.9.  Program  Management  and  Assessment.  Acquisition  programs  require  dedicated 
management.  This  part  describes  assignment  of  Program  Managers,  assignment  of  Program 
Executive  Officers,  and  the  use  of  Integrated  Product  Teams. 

4.9.1.  Assignment  of  Program  Managers.  A  PM  shall  be  designated  for  each  acquisition 
program.  This  designation  shall  be  made  no  later  than  program  initiation.  It  is  essential  that  the 
PM  have  an  understanding  of  user  needs  and  constraints,  familiarity  with  development 
principles,  and  requisite  management  skills  and  experience.  If  the  acquisition  is  for  services,  the 
PM  shall  be  familiar  with  DoD  guidance  on  acquisition  of  services.  A  PM  and  a  deputy  PM  of 
an  ACAT  I  or  II  program  shall  be  assigned  to  the  position  at  least  until  completion  of  the  major 
milestone  that  occurs  closest  in  time  to  the  date  on  which  the  person  has  served  in  the  position 
for  four  years  in  accordance  with  the  Defense  Acquisition  Workforce  Improvement  Act 
(DAWIA)  (reference  (ff)).  Upon  designation,  the  program  manager  shall  be  given  budget 
guidance  and  a  written  charter  of  his  or  her  authority,  responsibility,  and  accountability  for 
accomplishing  approved  program  objectives. 

4.9.2.  Assignment  of  Program  Executive  Responsibility.  Unless  a  waiver  is  granted  for  a 
particular  program  by  the  USD(AT&L)  or  the  ASD(C3I),  CAEs  shall  assign  acquisition  program 
responsibilities  to  a  PEO  for  all  ACAT  I,  ACAT  IA,  and  sensitive  classified  programs,  or  for  any 
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other  program  determined  by  the  CAE  to  require  dedicated  executive  management.  The  PEO 
shall  be  dedicated  to  executive  management  and  shall  not  have  other  command  responsibilities. 
The  CAE  shall  make  this  assignment  no  later  than  program  initiation;  or  within  three  months  of 
estimated  total  program  cost  reaching  the  appropriate  dollar  threshold  for  ACAT I  and  ACAT IA 
programs.  CAEs  may  determine  that  a  specific  PM  shall  report  directly,  without  being  assigned 
to  a  PEO,  whenever  such  direct  reporting  is  appropriate.  The  CAE  shall  notify  the  USD(AT&L) 
or  the  ASD(C3I)  of  the  decision  to  have  a  PM  report  directly  to  the  CAE.  Acquisition  program 
responsibilities  for  programs  not  assigned  to  a  PEO  or  a  direct-reporting  PM  shall  be  assigned  to 
a  commander  of  a  systems,  logistics,  or  materiel  command.  In  order  to  transition  from  a  PEO  to 
a  commander  of  a  systems,  logistics,  or  materiel  command,  a  program  or  block  of  capability 
shall,  at  a  minimum,  have  passed  Initial  Operating  Capability  (IOC),  have  achieved  frill-rate 
production,  be  certified  as  interoperable  within  the  intended  operational  environment,  and  be 
supportable  as  planned. 

4.9.3.  Integrated  Product  Teams  in  the  Oversight  and  Review  Process.  Defense 
acquisition  works  best  when  all  of  the  DoD  Components  work  together  cooperatively  to  share 
data  and  information  of  all  types,  and  the  workforce  is  empowered.  Each  DoD  Component  shall 
implement  the  concepts  of  Integrated  Product  and  Process  Development  (IPPD)  and  Integrated 
Product  Teams  (IPTs)  as  extensively  as  possible.  All  appropriate  functional  disciplines  and  the 
DoD  Components  shall  participate  in  IPTs  to  the  maximum  extent  practical  and  useful. 

4.9.4.  Decision  Reviews.  At  each  milestone  and  other  points  in  the  process  where 
desired  by  the  MDA,  the  Milestone  Decision  Authority  shall  review  each  technology  project  or 
acquisition  program.  The  MDA  shall  review  the  Program  Manager's  program,  as  informed  by 
the  IPT  process,  and  the  independent  assessments  required  by  law  or  die  MDA's  judgment. 

5.  EFFECTIVE  DATE 

This  Instruction  is  effective  immediately. 
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El.  ENCLOSURE  1 
REFERENCES,  continued 


(e)  Under  Secretary  of  Defense  (AT&L),  Assistant  Secretary  of  Defense  (C3I),  and  Director, 
Operational  Test  and  Evaluation,  "Defense  Acquisition  Policy  Steering  Group  and  Defense 
Acquisition  Policy  Working  Group  Charter,"  August  5,  1999 

(f)  Defense  Acquisition  Deskbook,  www.deskbook.osd.mil 

(g)  DoD  Directive  5000.1,  "Defense  Acquisition,"  March  15,  1996  (canceled) 

(h)  DoD  5000.2-R,  "Mandatory  Procedures  for  Major  Defense  Acquisition  Programs  and  Major 
Automated  Information  Systems,"  March  1996  (canceled) 

(0  CJCS  Instruction  3 170.01  A,  "Requirements  Generation  System,"  August  10, 1999 

(j)  DoD  7000. 14-R,  "DoD  Financial  Management  Regulation,"  Volumes  2A  and  2B,  "Budget 
Presentation  and  Formation,"  July  1998 

(k)  DoD  Directive  5200.39,  “Security,  Intelligence,  and  Counterintelligence  Support  to 
Acquisition  Program  Protection,”  September  10, 1997 

(l)  DoD  Directive  5230.1 1,  “Disclosure  of  Classified  Military  Information  to  Foreign 
Governments  and  International  Organizations,”  June  16,  1992 

(m)  Section  1401  et  seq.  of  title  40,  United  States  Code,  "Clinger-Cohen  Act  of  1996" 

(n)  DoD  Directive  8000.1,  "Defense  Information  Management  (IM)  Program,"  October  27,  1992 

(o)  DoD  Directive  8320.1,  "DoD  Data  Administration,"  September  26,  1991 

(p)  DoD  Directive  4630.5,  "Compatibility,  Interoperability,  and  Integration  of  Command, 
Control,  Communications,  and  Intelligence  (C3I)  Systems,"  November  12, 1992 

(q)  DoD  Instruction  4630.8,  "Procedures  for  Compatibility,  Interoperability,  and  Integration  of 
Command,  Control,  Communications,  and  Intelligence  (C3I)  Systems,"  November  18, 1992 

(r)  CJCS  Instruction  6212.01B,  "Interoperability  and  Supportability  on  National  Security 
Systems,  and  Information  Technology  Systems,"  May  14,  2000 

(s)  Federal  Acquisition  Regulation,  Part  15.404-1,  "Proposal  Analysis  Techniques" 

(t)  )  Section  2350a  of  title  10,  United  States  Code,  "Cooperative  Research  and  Development 

Programs:  Allied  Countries" 

(u)  Fiscal  Year  2001  DoD  Appropriations  Act,  Section  8102  (Pub.  L.  106-259) 

(v)  Section  794  of  title  29,  United  States  Code,  "Rehabilitation  Act" 

(w)  Section  2364  of  title  10,  United  States  Code,  "Coordination  and  Communication  of  Defense 
Research  Activities” 

(x)  Government  Performance  and  Results  Act  (Pub.  L.  103-62) 

(y)  Section  2366  of  title  10,  United  States  Code,  "Major  Systems  and  Munitions  Programs: 
Survivability  and  Lethality  Testing  Required  Before  Full-scale  Production" 

(z)  Section  306  of  title  5,  United  States  Code,  "Strategic  Plans"  (part  of  the  Government 
Performance  and  Results  Act) 

(aa)  Section  4321  et  seq.  of  title  42,  United  States  Code,  "National  Environmental  Policy  Act" 
(bb)  DoD  7000. 14-R,  "  DoD  Financial  Management  Regulation,"  Volume  2A,  "Budget 

Presentation  and  Formation,"  Chapter  1,  "General  Information,"  Section  010212,  "Research, 
Development,  Test,  and  Evaluation-Selection  and  Criteria" 

(cc)  Section  139  of  title  10,  United  States  Code,  "Director  of  Operational  Test  and  Evaluation" 
(dd)  Section  2400  of  title  10,  United  States  Code,  "Low-rate  Initial  Production  of  New  Systems" 
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(ee)  Section  3501  et  seq.  of  title  44,  United  States  Code,  "Paperwork  Reduction  Act  of  1980" 
(ff)  Section  1734  of  title  10,  United  States  Code,  "Career  Development" 

(gg)  Section  2430  of  title  10,  United  States  Code,  "Major  Defense  Acquisition  Program 
Defined" 

(hh)  Section  2302d  of  title  10,  United  States  Code,  "Major  System:  Definitional  Threshold 
Amounts" 

(ii)  DoD  5000 .4-M,  "Cost  Analysis  Guidance  and  Procedures,"  December  1992 
(jj)  Section  2377  of  title  10,  United  States  Code,  "Preference  for  Acquisition  of  Commercial 
Items" 

(kk)  Section  2435  of  title  10,  United  States  Code,  "Baseline  Description" 

(11)  Section  2432  of  title  10,  United  States  Code,  "Selected  Acquisition  Reports" 

(mm)  Section  2433  of  title  10,  United  States  Code,  "Unit  Cost  Reports" 

(nn)  Section  2440  of  title  10,  United  States  Code,  "Technology  and  Industrial  Base  Plans" 

(oo)  Section  2434  of  title  10,  United  States  Code,  "Independent  Cost  Estimates;  Operational 
Manpower  Requirements" 

(pp)  Section  2399  of  title  10,  United  States  Code,  "Operational  Test  and  Evaluation  of  Defense 
Acquisition  Programs" 

(qq)  Section  8 1 1  of  the  National  Defense  Authorization  Act  for  Fiscal  Year  2001  (Pub.  L.  106- 
398) 

(rr)  Section  305  of  title  47,  United  States  Code,  "Government-Owned  Stations" 

(ss)  Section  104  of  the  National  Telecommunications  and  Information  Organization  Act, 
"Spectrum  Management  Activities"  (Pub.  L.  102-538) 

(tt)  Sections  901,  902,  903,  and  904  of  title  47,  United  States  Code 

(uu)  Section  2464  of  title  10,  United  States  Code,  "Core  "Logistics  Functions" 

(w)  Section  2460  of  title  10,  United  States  Code,  "Definition  of  Depot-Level  Maintenance  and 
Repair" 

(ww)  Section  2466  of  title  10,  United  States  Code,  "Limitations  on  the  Performance  of  Depot- 
Level  Maintenance  of  Material" 

(xx)  Section  2469  of  title  10,  United  States  Code,  "Contracts  to  Perform  Workloads  Previously 
Performed  by  Depot-Level  Activities  of  the  Department  of  Defense:  Requirement  of 
Competition" 

(yy)  DoD  Directive  5105.21,  "Defense  Intelligence  Agency,"  February  18, 1997 
(zz)  DoD  5200.1-M,  "Acquisition  System  Program  Protection,"  March  16, 1994 
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E2.  ENCLOSURE  2 
DEFINITIONS 


E2.1.1.  Acquisition  Executive.  The  individual  within  the  Department  and  Components 
charged  with  overall  acquisition  management  responsibilities  within  his  or  her  respective 
organization.  The  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  is  the 
Defense  Acquisition  Executive  (DAE)  responsible  for  all  acquisition  matters  within  the 
Department  or  Defense.  The  Component  Acquisition  Executives  (CAEs)  for  each  of  the 
Components  are  the  Secretary  of  the  Military  Departments  or  the  Heads  of  Agencies  with  power 
of  redelegation.  The  CAEs  are  responsible  for  all  acquisition  matters  within  their  respective 
Component. 

E2.1.2.  Acquisition  Program.  A  directed,  funded  effort  designed  to  provide  a  new, 
improved,  or  continuing  materiel,  weapon,  or  information  system  or  service  capability  in 
response  to  a  validated  operational  or  business  need.  Acquisition  programs  are  divided  into 
different  categories  that  are  established  to  facilitate  decentralized  decision-making,  execution, 
and  compliance  with  statutory  requirements.  Technology  projects  are  not  acquisition  programs. 

E2.1 .3.  Anti-Tampering  (AT).  The  system  engineering  activities  intended  to  prevent  and/or 
delay  exploitation  of  critical  technologies  in  U.S.  systems.  These  activities  involve  the  entire 
life-cycle  of  systems  acquisition,  including  research,  design,  development,  testing, 
implementation,  and  validation  of  anti-temper  measures.  Properly  employed,  anti-tamper 
measures  will  add  longevity  to  a  critical  technology  by  deterring  efforts  to  reverse-engineer, 
exploit,  or  develop  countermeasures  against  a  system  or  system  component. 

E2. 1 .4.  Automated  Information  System  (AISL  An  acquisition  program  that  acquires 
Information  Technology  (IT),  except  IT  that: 

E2. 1.4.1.  Involves  equipment  that  is  an  integral  part  of  a  weapon  or  weapons  system;  or 

E2. 1 .4.2.  Is  a  tactical  communication  system. 

E2.1.5.  Information  Technology  (IT).  Any  equipment,  or  interconnected  system  or 
subsystem  of  equipment,  that  is  used  in  the  automatic  acquisition,  storage,  manipulation, 
management,  movement,  control,  display,  switching,  interchange,  transmission,  or  reception  of 
data  or  information. 

E2. 1.5.1.  The  term  "equipment"  means  any  equipment  used  by  a  Component  directly  or 
used  by  a  contractor  under  a  contract  with  the  Component  that  requires  the  use  of  such 
equipment,  or  the  use,  to  a  significant  extent,  of  such  equipment  in  the  performance  of  a  service 
or  the  furnishing  of  a  product. 

E2. 1.5.2.  The  term  "IT"  includes  computers,  ancillary  equipment,  software,  firmware 
and  similar  procedures,  services  (including  support  services),  and  related  resources.  The  term 
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"IT"  also  includes  National  Security  Systems  (NSSs).  It  does  not  include  any  equipment  that  is 
acquired  by  a  Federal  contractor  incidental  to  a  Federal  contract. 

E2. 1.5.3.  This  definition  is  from  the  CCA  (reference  (m)). 

E2.1.6.  Integrated  Product  and  Process  Development  tlPPDl.  A  management  process  that 
integrates  all  activities  from  product  concept  through  production  and  support,  using  a 
multifunctional  team,  to  simultaneously  optimize  the  product  and  its  manufacturing  and 
sustainment  processes  to  meet  cost,  schedule,  and  performance  objectives. 

E2.1.7.  Integrated  Product  Team  (IPT).  A  multifunctional  team  assembled  around  a  product 
or  service,  and  responsible  for  advising  the  project  leader,  Program  Manager,  or  MDA  on  cost, 
schedule,  and  performance  of  that  product.  There  are  three  types  of  IPTs:  Program  IPTs, 
Working-level  IPTs,  and  Overarching  IPTs. 

E2.1.8.  Major  Automated  Information  System  fMAISl 

E2. 1.8.1.  An  AIS  that  is  designated  by  ASD(C3I)  as  a  MAIS,  or  estimated  to  require 
program  costs  in  any  single  year  in  excess  of  $32  million  in  fiscal  year  (FY)  2000  constant 
dollars,  total  program  costs  in  excess  of  $126  million  in  FY  2000  constant  dollars,  or  total  life- 
cycle  costs  in  excess  of  $378  million  in  FY  2000  constant  dollars. 

E2. 1.8.2.  MAISs  do  not  include  highly  sensitive  classified  programs  (as  determined  by 
the  Secretary  of  Defense)  or  tactical  communication  systems. 

E2. 1.8.3.  For  the  purpose  of  determining  whether  an  AIS  is  a  MAIS,  the  following  shall 
be  aggregated  and  considered  a  single  AIS: 

E2.1. 8.3.1.  The  separate  AISs  that  constitute  a  multi-element  program. 

E2.1. 8.3.2.  The  separate  AISs  that  make  up  an  evolutionary  or  incrementally 
developed  program. 

E2.1. 8.3.3.  The  separate  AISs  that  make  up  a  multi-DoD  Component  AIS  program. 

E2.1.9.  Major  Defense  Acquisition  Program  (MDAP) 

E2. 1.9.1.  An  acquisition  program  that  is  not  a  highly  sensitive  classified  program  (as 
determined  by  the  Secretary  of  Defense)  and  that  is  designated  by  the  Under  Secretary  of 
Defense  (Acquisition,  Technology,  and  Logistics)  (USD(AT&L))  as  an  MDAP,  or  estimated  by 
the  USD(AT&L)  to  require  an  eventual  total  expenditure  for  research,  development,  test  and 
evaluation  of  more  than  $365  million  in  fiscal  year  (FY)  2000  constant  dollars  or,  for 
procurement,  of  more  than  $2,190  billion  in  FY  2000  constant  dollars. 

E2. 1.9.2.  The  estimate  shall  consider  all  blocks  that  will  make  up  an  evolutionary 
acquisition  program  (to  the  extent  that  subsequent  blocks  can  be  defined). 
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E2.1.9.3.  This  definition  is  from  10  U.S.C.  2430  (reference  (gg)).  The  dollar 
requirements  are  established  in  statute  in  FY  1990  dollars.  The  dollar  amounts  have  been 
updated  in  accordance  with  procedures  identified  in  the  statute. 

E2.1.10.  Major  System  A  combination  of  elements  that  shall  function  together  to  produce 
the  capabilities  required  to  fulfill  a  mission  need,  including  hardware,  equipment,  software,  or 
any  combination  thereof,  but  excluding  construction  or  other  improvements  to  real  property. 

E2. 1.1 0.1.  A  system  shall  be  considered  a  major  system  if  it  is  estimated  by  the  DoD 
Component  Head  to  require  an  eventual  total  expenditure  for  RDT&E  of  more  than  $140  million 
in  FY  2000  constant  dollars,  or  for  procurement  of  more  than  $660  million  in  FY  2000  constant 
dollars,  or  if  designated  as  major  by  the  DoD  Component  Head  (10  U.S.C.  §2302d,  reference 
(hli)). 


E2. 1.10.2.  The  estimate  shall  consider  all  blocks  that  will  make  up  an  evolutionary 
acquisition  program  (to  the  extent  subsequent  blocks  can  be  defined). 

E2. 1.10.3.  The  dollar  requirements  are  established  in  statute  in  FY  1990  dollars.  The 
dollar  amounts  have  been  updated  in  accordance  with  procedures  identified  in  the  statute. 

E2.1.11.  Milestone  Decision  Authority  (MPA).  The  individual  designated  in  accordance 
with  criteria  established  by  the  USD(AT&L),  or  by  the  ASD(C3I)  for  AIS  acquisition  programs, 
to  approve  entry  of  an  acquisition  program  into  the  next  phase  of  the  acquisition  process. 

E2.1.12.  Mission  Critical  Information  System  A  system  that  meets  the  definitions  of 
“information  system”  and  “national  security  system”  in  the  Clinger-Cohen  Act,  the  loss  of  which 
would  cause  the  stoppage  of  warfighter  operations  or  direct  mission  support  of  warfighter 
operations.  (Note:  The  designation  of  mission  critical  should  be  made  by  a  Component  Head,  a 
CINC  or  their  designee.)  A  Mission  Critical  Information  Technology  System  has  the  same 
meaning  as  a  Mission  Critical  Information  System. 

E2.1.13.  Mission  Essential  Information  System.  A  system  that  meets  the  definition  of 
“information  system”  in  the  Clinger-Cohen  Act,  that  the  acquiring  Component  Head  or  designee 
determines  is  basic  and  necessary  for  the  accomplishment  of  the  organizational  mission.  (Note: 
The  designation  of  mission  essential  should  be  made  by  a  Component  Head,  a  CINC  or  their 
designee.)  A  Mission  Essential  Information  Technology  System  has  the  same  meaning  as  a 
Mission  Essential  Information  System. 

E2.1.14.  National  Security  System  (NSS).  Any  telecommunications  or  information  system 
operated  by  the  U.S.  Government,  the  function,  operation,  or  use  of  which: 

E2. 1 . 14. 1 .  Involves  intelligence  activities; 

E2. 1.1 4.2.  Involves  cryptologic  activities  related  to  national  security; 
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E2. 1.14.3.  Involves  command  and  control  of  military  forces; 

E2. 1 . 1 4.4.  Involves  equipment  that  is  an  integral  part  of  a  weapon  or  weapons  system; 
or, 

E2. 1.14.5.  Subject  to  the  limitation  below,  is  critical  to  the  direct  fulfillment  of  military 
or  intelligence  missions.  This  does  not  include  a  system  that  is  to  be  used  for  routine 
administrative  and  business  applications  (including  payroll,  finance,  logistics,  and  personnel 
management  applications). 

E2. 1.1 4.6.  This  definition  is  from  the  Clinger-Cohen  Act  (reference  (m)). 

E2.1.15.  Overarching  Integrated  Product  Team  (OIPT)  Leader.  The  person  in  the  Office  of 
the  Secretary  of  Defense  who  leads  the  Overarching  Integrated  Product  Team  and  is  responsible 
for  providing  an  assessment  of  each  assigned  program.  The  OIPT  Leader  is  not  in  the  decision¬ 
making  line  of  authority  for  programs. 

E2.1.16.  Program  Executive  Officer  (PEO).  A  military  or  civilian  official  who  has  primary 
responsibility  for  directing  several  MDAPs  and  for  assigned  major  system  and  non-major  system 
acquisition  programs.  A  PEO  has  no  other  command  or  staff  responsibilities  within  the 
Component,  and  only  reports  to  and  receives  guidance  and  direction  from  the  DoD  Component 
Acquisition  Executive. 

E2.1.17.  Program  Manager  (PM).  The  individual  designated  in  accordance  with  criteria 
established  by  the  appropriate  Component  Acquisition  Executive  to  manage  an  acquisition 
program  and  is  appropriately  certified  under  the  provisions  of  the  DAWLA  (reference  (ff)).  A 
PM  has  no  other  command  or  staff  responsibilities  within  the  Component. 

E2.1.18.  Requirements  Authority.  The  individual  within  the  DoD  Components  charged  with 
overall  requirements  definition  and  validation.  The  Vice-Chairman  of  the  Joint  Chiefs  of  Staff, 
in  the  role  as  Chairman  of  the  JROC,  is  the  requirements  authority  for  all  potential  major  defense 
acquisition  programs  and  is  responsible  for  all  requirements  policy  and  procedures,  including 
MNSs,  CRDs,  and  ORDs.  The  Requirements  Authority  for  other  acquisition  category  programs 
is  specified  in  reference  (i). 

E2.1.19.  Technology  Project  A  directed,  incrementally  funded  effort  designed  to  provide 
new  capability  in  response  to  technological  opportunities  or  an  operational  or  business  (e.g., 
accounting,  inventory  cataloging,  etc.)  need.  Technology  projects  are  "pre-systems  acquisition," 
do  not  have  an  acquisition  category,  and  precede  program  initiation.  Technology  is  the  output  of 
the  science  and  technology  program  that  is  used  in  systems  acquisition.  The  decision  authority 
and  information  necessary  for  decision-making  on  each  project  shall  be  specified  by  the 
appropriate  S&T  Executive  (for  projects  not  yet  approved  for  Milestone  A)  or  by  the  MDA  (for 
projects  past  Milestone  A). 

E2.1.20.  Total  Ownership  Cost  (TOC).  The  sum  of  financial  resources  to  organize,  equip, 
sustain,  and  operate  military  forces  to  meet  national  goals,  policies,  and  standards  of  readiness, 
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environmental  compliance,  safety,  and  quality  of  life  concerns.  The  TOC  for  Defense  systems 
consists  of  the  costs  to  research,  develop,  acquire,  own,  operate,  and  dispose  of  weapon  and 
support  systems.  It  includes  direct  costs  and  indirect  costs  attributable  to  the  systems  and 
infrastructure  costs  not  directly  attributable  to  the  system.  Product  support  mainly  concerns  the 
portion  of  TOC  that  occurs  after  the  system  is  deployed  (the  sustainment  and  disposal  phase  of  a 
system's  life  cycle).  For  purposes  of  costing,  the  PM  shall  use  life-cycle  costs  as  defined  in  DoD 
5000.4-M  (reference  (ii)). 

E2.1.21.  Weapon  System  An  item  or  set  of  items  that  can  be  used  directly  by  warfighters  to 
carry  out  combat  or  combat  support  missions  to  include  tactical  communication  systems. 
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E3.  ENCLOSURE  3 

STATUTORY  AND  REGULATORY  INFORMATION 


E3.1.1.  Tables  1  and  2,  below,  show  the  information  requirements  for  all  milestones,  both 
statutory  and  regulatory. 

For  AIS  programs,  the  information  in  this  table  except  for  CCA  compliance  is  regulatory,  not 
statutory,  unless  otherwise  stated  or  the  AIS  is  a  MDAP.  Acquisition  Program  Baselines  and 
Industrial  Capabilities,  below,  for  MDAPs  are  required  by  the  statute  cited.  For  non-MDAPs, 
they  are  required  by  this  Instruction. 

E3.T1.  Table  1.  Statuatory  Information  Requirements 


INFORMATION  REQUIRED 

APPLICABLE  STATUTE 

WHEN  REQUIRED 

Consideration  of  Technology  Issues 

10  U.S.C.§  2364  (reference  (w)) 

Milestone  (MS)  A 

MSB 

MSC  i 

Market  Research 

10  U.S.C.  §2377  (reference  ®) 

Technology  Opportunities  User 

Needs 

MSA 

MSB 

Acquisition  Program  Baseline  (APB) 

10  U.S.C. §2435  (reference  (kk)) 

Component  Advanced  Development 
Decision  Review  (DR)  (if  Program 
Initiation) 

MSB 

MS  C  (updated,  as  necessary) 
Full-Rate  Production  DR 

Compliance  with  Strategic  Plan  (as 
part  of  the  analysis  of  alternatives, 
whenever  practical) 

5  U.SC  §306  (reference  (z)) 

MSB 

MSC 

Selected  Acquisition  Report  (SAR) 
(MDAPs  only)  Unit  Cost  Report 
(UCR) 

10  U.S.C. §2432  (reference  (11)) 

Component  Advanced  Development 
DR  (if  Program  Initiation) 

MSB 

(MDAPs  only) 

10  U.S.C.§2433  (reference  (mm)) 

MSC 

Full-Rate  Production  DR 

Live  Fire  Waiver  &  alternate  LFT&E 
Plan 

(Covered  Systems  only) 

10  U.S.C.§2366  (reference  (y)) 

MSB 

Industrial  Capabilities  (part  of 
acquisition  strategy) 

(N/Afor  AISs) 

10  U.S.C.§2440  (reference  (nn)) 

MSB 

MSC 

LRIP  Quantities 
(N/Afor  AISs) 

10  U.S.C. §2400  (reference  (dd)) 

MSB 

Independent  Cost  Estimate  and 

10  U.S.C.§2434  (reference  (oo)) 

MSB 

Manpower  Estimate 

DoDI  5000.2  (this  Instruction) 

MSC  (ICE  only) 

(N/A  for  AISs)  (MDAPs  Only) 

10  U.S.C.  .§2434  (reference  (oo)) 

Full-Rate  Production  DR 

Operational  Test  Plan 
(DOT&E  Oversight  Programs  only) 

10  U.S.C.§2399  (reference  (pp)) 

Prior  to  start  of  operational  test  and 
evaluation 

10  U.S.C.§2350a  (reference  (t)) 

MSB 

MSC 

5  U.S.C. §306  (reference  (z)) 

40  U.S.C.§1401etseg.  (reference 
(m)) 

Full-Rate  Production  DR 
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E3.T1.  Table  1.  Statuatory  Information  Requirements,  continued 


INFORMATION  REQUIRED 

APPLICABLE  STATUTE 

WHEN  REQUIRED 

Beyond-LRIP  Report 

(OSD  T&E  Oversight  programs  only) 

10  U.S.C.§2399  (reference  (oo)) 

Full-Rate  Production  DR 

LFT&E  Report 

OSD-covered  proqrams  only) 

10  U.S.C.§2366  (reference  (vy) 

Full-Rate  Production  DR 

Clinger-Cohen  Act  (CCA) 

Compliance 

(All  IT  -including  NSS)  (See  Table 

3) 

40  U.S.C.§1401  etseg.  (reference 
(u)) 

Component  Advanced  Development 
DR  (if  Program  Initiation) 

MSB 

MS  C 

Full-Rate  Production  DR 

CCA  Certification  to  Congressional 
Defense  Committees  for  MAIS  (See 
Table  3) 

Pub.  L.  106-259,  Section  81 02 
(reference  (u)) 

Component  Advanced  Development 
DR  (if  Program  Initiation) 

MSB 

MSC 

Full-Rate  Production  DR 

Pub.L.  106-259,  Section  8102 
(reference  (u)) 

Pub.L  106-398,  Section  811 
(reference  qq) 

Component  Advanced  Development 
DR  (if  Program  initiation) 

MS  B  (if  Program  Initiation) 

MS  C  (if  Proqram  Initiation) 

Application  for  Frequency  Allocation 
(DD  Form  1494)  (applicable  to  all 
systems/equipment  that  require 
utilization  of  the  electromagnetic 
spectrum) 

47  U.S.C.  §305  (reference  (rr)) 

Pub.  L.  102-538,  §104  (reference 
(ss)) 

47  U.S.C.  §901-904  (reference  (tt)) 

MSB 

MSC  (if  no  MS  B) 

National  Environmental,  Policy  Act 
Schedule 

42  U.S.C.§4321  (reference  (aa)) 

Component  Advanced  Development 
DR  (if  Program  Initiation) 

MSB 

MSC 

Full-Rate  Production  DR 

Core  Logistics  Analysis/Source  of 
Repair  Analysis  (part  of  acquisition 
strategy) 

10  U.S.C.  §2464  (reference  (uu)) 

10  U.S.C.  §2460  (reference  (w)) 

10  U.S.C.  §2466  (reference  (ww)) 

MSB 

MSC  (if  no  MS  B) 

Competition  Analysis  ($3M  rule)  (part 
of  acquisition  strategy) 

10. U.S.C.  §2469  (reference  (xx)) 

MSB 

MS  C  (if  no  MS  B) 

E3.1.2.  All  requirements  are  from  this  Instruction  or  DoD  5000.2-R.  (reference  (h)),  unless 
otherwise  noted. 


E3.T2.  Table  2.  Regulatory  Information  Requirements 


INFORMATION  REQUIRED 

WHEN  REQUIRED 

Validated  Mission  Need  Statement  (MNS) 

(source:  CJCS  Instruction  3170.01  A,  reference  (i)) 

MSA 

Validated  Operational  Requirements  Document  (ORD) 

MSB 

(source:  CJCS  Instruction  3170.01  A,  reference  (i)) 

MSC 

Acquisition  Strategy 

Component  Advanced  Development  DR  (if  Program 
Initiation) 

MSB 

MSC 

Full-Rate  Production  DR 

Analysis  of  Multiple  Concepts 

MSA 

Analysis  of  Alternatives  (AoA) 

MSB 

MSC  (if  no  MS  B) 
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System  Threat  Assessment 

MSB 

(N/A  for  AISs)  (validated  by  DIA  for  ACAT  ID  programs) 

MSC 

(source:  DoD  Directive  5105.21  (reference  (yy))) 

Independent  Technology  Assessment 

MSB 

MSC 

C41SP  (also  summarized  in  the  acquisition  strategy) 

Component  Advanced  Development  DR  (if  Program 

Initiation) 

MSB 

MSC 

E3.T2.  Table  2.  Regulatory  Information  Requirements,  continued 


INFORMATION  REQUIRED 

WHEN  REQUIRED 

C4I  Supportability  Certification 

Full-Rate  Production  DR 

Interoperability  Certification 

Full-Rate  Production  DR 

Affordability  Assessment 

MSB 

MSC 

Economic  Analysis  (MAISs  only) 

MSB 

Component  Cost  Analysis  (mandatory  for  MAIS;  as 

MS  B  (for  MAIS,  each  time  the  MDA  requests  an 

requested  by  CAE  for  MDAP) 

Economic  Analysis 

Full-Rate  Production  DR  (MDAPs  only) 

Cost  Analysis  Requirements  Description 

MSB 

(MDAPs  only) 

MSC 

Full-Rate  Production  DR 

Test  and  Evaluation  Master  Plan  (TEMP) 

MS  A  (evaluation  strategy  only) 

MS  B  ”  ! 

MS  C  (update,  if  necessary) 

Full-Rate  Production  DR 

Operational  Test  Activity  Report  of  Operational  Test  and 

MSB 

Evaluation  Results 

MSC 

Full-Rate  Production  DR 

Component  Live  Fire  Test  and  Evaluation  Report 
(Covered  Systems  Only) 

Completion  of  Live  Fire  Test  and  Evaluation 

Program  Protection  Plan  (PPP) 

MS  B  (based  on  validated  requirements  in  ORD) 

(also  summarized  in  the  acquisition  strategy) 

(source:  DoD  5200. 1-M,  reference  (zz)) 

MSC 

Exit  Criteria 

MSA 

MSB 

MSC 

Each  Review 

ADM 

MSA 

MSB 

MSC 

Each  Review 
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DODI  5000.2,  Change  1 


Mission-Critical  and  Mission- 
Essential  Information  Systems 

As  required  by  Sec.  8102(b)  of 
the  DoD  Appropriations  Act, 
2001  (Pub.  L 106-398,  Section 


DODI  50002,  Change  1 
Sections 


Comply  with  CCA 

Yes 

Yes 

Confirm  CCA  Compfianoe  to  MDA 

Yes 

Yes 

Certify  CCA  Compliance  to  DOD 
CIO 

No 

No 

Register  System  with  DOD  CIO 

Yes 

Yes 

No  contracts  awarded  until: 

1)  System  is  registered  with 
DOD  CIO 

2)  DOD  CIO  determines 
information  assurance  strategy 
is  appropriate 

3)  System  being  developed 
IAWCCA 

Yes 

Yes 

CO  /  CO 


Yes  Yes  Yes 


Yes  Yes  Yes  |  Yes 


4.7.32.3.2  thru  4.7.3.2.3.24  and 

47.3.3.3.2  thru  4.7.3.3.32.2 


Yes  Yes  Yes 


No  No  No  4.7.32.32  thru  4.7.3.2.32.4 


No  No  No  4.7.32.3.2  thru  4.7.32.32.4 


No  No  No  4.7.32.3.2.1.11 


No  No  No  47.3.1.5  and  47.3.1. 5.1 
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INTERNET  DOCUMENT  INFORMATION  FORM 


A .  Report  Title:  Operation  of  the  Defense  Acquisition  System 


B.  DATE  Report  Downloaded  From  the  Internet:  11/14/01 


C.  Report's  Point  of  Contact:  (Name,  Organization,  Address,  Office 
Symbol,  &  Ph  #):  The  Under  Secretary  of  Defense 

3010  Defense  Pentagon 
Washington,  DC  20301-3010 


D.  Currently  Applicable  Classification  Level:  Unclassified 


E.  Distribution  Statement  A:  Approved  for  Public  Release 

F.  The  foregoing  information  was  compiled  and  provided  by: 

DTIC-OCA,  Initials: _ VM _ Preparation  Date  11/14/01 


The  foregoing  information  should  exactly  correspond  to  the  Title,  Report  Number,  and  the  Date 
the  accompanying  report  document.  If  there  are  mismatches,  or  other  questions,  contact  the 
above  OCA  Representative  for  resolution. 


